I find it disturbing how many people on this thread do not seem to get it. Anyone that believes that VBA support in Office:Mac is unimportant and that running Office for Windows in virtualization through Parallels or natively in Boot Camp is the ultimate solution to running Office on a Mac is either nave, living in a fantasy world or plain stupid. Sorry if anyone take that as an insult, but it needed to be stated. Microsoft knows exactly what they are doing by dropping VBA support for the Mac and it is nothing short of puerile logic to believe that this move is in any way a positive for Mac users.
First and foremost, Office compatibility is a big deal for the Mac. While many on this thread have proposed that they can live Microsoft-free on their Macs, the simple fact of the matter is that we do live in a Windows-centric world and Microsoft Office is not something that most Mac users can do without whether they prefer to use it or not. Until there is a dramatic shift in the market share of productivity suites, Office:mac needs to exist and it needs to be compatible with the Windows version.
Scripting capabilities are also very important and Microsoft has been very lackluster in that department. While some erroneously believe that VBA is not used extensively anyone that has ever taken the time to peruse an Excel user forum and browse the Macro/VBA threads will easily see that VBA, particularly in Excel, is very important. I, and many others in my department, use VBA all of the time to automate spreadsheets. In fact, the Bioresources Engineering Department, from which I received my Bachelors Degree, added a required course in Visual Basic five years ago to the curriculum because they found it to be a rsum booster for the engineering technology students. The director of my current graduate program, who also teaches courses in engineering tech, realized how powerful Excels scripting capabilities were as a data processing tool and he now strongly recommends that operations research grads learn VBA to bolster their rsums along with their SAS skills.
In the past 2+ years of graduate school I have developed several useful VBA scripts, some to the point of software development:
- A project for our Cooperative Extension group that allowed them to conduct studies on ammonia emissions from litter in poultry houses with Jones-Hamilton. The software provides daily, weekly and overall flock grow-out ammonia emissions from sensors that take readings every minute; that is 10,800 data records per week or 60,480 to 70,560 data records per flock. UDCE is still using this software for their litter experiments.
- For our research in poultry depopulation using fire-fighting foam (AVMA and USDA approved 6 NOV 2006) an accelerometer and ECG equipment were used to track animal vital signs during experimental trials. As more data points were generated per bird over the five-minute test period than Excel can graph, I wrote a program that would filter the waveforms down to less than 32,000 data points so that charts could be recreated in Excel and analyzed.
- For a case study in optimization my project partner and I developed a software package that could be used by coaches to make dynamic best player selections in childrens basketball leagues that require all team members get court time.
- For another class assignment functionality was added to an Excel workbook that converts a data set into a CSV file for transfer into SAS for linear regression analysis and two other data setstraining and verificationfor use in neural network software. The latter required splitting the base data set into two sets via random selection and also includes the ability to add lagged data sets. The new functions are accessed through Excel menus and appear to be part of the application. That program has been and is still being used by subsequent operations research graduates in their neural network seminar and they are required to view and understand the underlying code.
These projects could have been done without automated spreadsheets, but as such the analysis that these programs perform would not be usable by persons unfamiliar with the ins and outs of Excel, they would take much longer to perform their analyses, would often not be able to easily import and process numerous data sets and most importantly would be more prone to erroneous computations.
Just in the past two weeks I had to analyze a huge data set for a research paper that would have taken me a month or more to complete if I could not have written a macro to do the calculations automatically. Also, because the macro was written in VBA it works on my Mac at home where it was authored and on the Wintel PCs in my lab where others needed to be able to review my work. Upon seeing my report to fulfill my course requirement for my independent study, the director of my grad program now wishes me to alter the paper for submission as a refereed paper. To do so, I will need to make some adjustments to the cost analysis using shorter timer periods, effectively doubling the size of the analysis. Where it not for the fact that I was able to automate the calculations, what now requires a tweak of two worksheets and a minor modification of my VBA codeall of which can be done in a day, including the modifications to the paperwould easily become several days of work just to insure that the new cost analysis tables are correctly computed.
Applescript and Automator work well in their own rights, but those technologies are not available on Windows and had I been able to and chose to automate my spreadsheets with those technologies, I would be very much SOL when it came time to present my work to the professor for whom I did the research. By, the flawed logic that Apples scripting technologies could simply replace VBA as a viable alternative, I could have just as well used REALbasic to create my macros given that REALbasic is cross-platform. Of course, while Office:mac supports using REALbasic scripts, Office for Windows does not and most likely never will quite on purpose.
Where writing scripts has save me work countless times, as I often process large data sets, Microsofts half-as
ed support of VBA on the Mac has made cross-platform usage of VBA troublesome. While most of my purely computational VBA programs work well across platforms, any software that I have built upon Excel to make it easier for clients to process multiple data sets of the same type tend to break on my Mac. Why? Because Microsoft has opted to not support enumerated types in VBA on the Mac nor add that one simple feature from as far back as Office 98 for Mac. Given that enumerated types are a fairly standard feature in most contemporary high-level programming languages, it is inexcusable for it to not be supported other than to break complex scripts authored on Wintel PCs when one attempts to run them on a Mac. It would be different if I were talking about support of Windows-only technologies like ActiveX, but enumerated types are not platform-dependent.
Now to those that erroneously think that running Office for Windows through virtualization is all that is necessary, here is only a few reasons why you are completely wrong:
- Mac users are Mac users because they do not wish to use Windows.
- The whole reason for the MBU was to create Microsoft applications that operate as Mac software is expected to work. Office for Windows does not use a Mac-centric UI and that very difference was the whole crux of the Word 5 fiasco and the reason the MBU came into existence. Mac users (rightfully) expect Mac software to look, feel and function as Mac software.
- Just because Macs can now run Windows in virtualization does not translate into Mac users wanting to run software that has been available for the Mac in Windows. If that were the case they would have never bought Macs in the first place. I guess you guys completely missed the several posts about concerns of developers doing this very thing and trivializing the Mac platformthat is obviously Microsofts ultimate goal.
- Running Office for Windows on a Mac forces Mac users to spend and additional $200 to $300 on software because all Mac users are not jumping on the virtualization bandwagon, nor do they need to given how they use their Macs. If Mac users are forced to buy the Windows version of Office then than means they also have to buy a copy of Windows even if they had no intention of running any other Windows-only software. It is bad enough that Mac users have to spend as much to buy Office:mac as they would to buy a copy of Office Professional Edition for Windows given that Office:mac lacks an entire application plus some, but to have to spend an additional $200 to $300 to run the exact same software is unacceptable.
- This move sets a bad precedent that other software developers will be watching very closely. If Microsoft bails on the Mac platform, you can best believe that other developers will use the economies of scale and virtualization arguments to the same end.
- As of now, Intel-based Macs make up a very small portion of the Macs in use and that will be the case for the next few years. Therefore, virtualization will not be a reality for most Mac users for quite some time. The Intel transition is just shy of a year in the making.
- And, one of the killer app points for many switchers is the fact that Office is available for the Mac. That availability is for many a huge make or break point in the decision to jump the Windows ship. If they are given the impression that they are going to have to deal with Windows anyway, then there is no compelling reason for their next computer to be a Mac. People may be willing to stop putting up with Windows, but Office is too deeply entrenched for just about anyone to abandon it given that for most peoples basic needs, Office works just fine.
Along with the decision to drop VirtualPC, instead of transitioning it into a virtualization product, the decision to drop VBA is just another step in weakening Office:mac, intentional or otherwise. Apple has been the golden egg as of late and Microsoft is not having it. Given that they got away with continuing with business as usual in the US, there is nothing to stop Microsoft from reversing its position on the Mac market. Where Microsoft relied on shear market dominance in the past they can no longer rest on that laurel as numerous, albeit a minority compared to the overall numbers of Windows users, continue to dump Wintel systems in favor of Macs. I, like the author, see this decision as a pre-emptive strike against the ever growing popularity of the Mac and the enlightenment of the masses to the fact that Microsoft has been pulling the wool over their eyes since the hype that was known as Windows 95.
Hopefully, someone out there is developing a kick-a
office productively suite that can open existing Mac and Windows Word, Excel, PowerPoint and Access files, but that blows away Microsoft Office. Said app should also support cross-platform scripting capabilities that blow away VBA; I am sure that REAL software would be more than willing to oblige any such developer in that area. Microsoft is obese with power and it is long overdue for a competitive b:oh slapping into humility.
“Cannot run out of time. There is infinite time. You are finite. Zathras is finite. This is wrong tool.”
2.3GHz Power Mac G5/4GB/500GB HDD/OS X 10.4.11/30-inch ACD,
60GB iPod (Color)
