[Hurley42]

You might want to inform universities worldwide about not using Excel for creating graphs of biological (and business school) data sets. It is currently the norm. :)

[lesls1]

Tell me again how many billion$ MS spends on R&D, then explain how Excel 2008 lacks support for VBS, and how Entourage lacks full support for MS Exchange Server.
If you believe these failings and shortcomings are not intentional, then I have title to a bridge you might be interested in buying...
Oh, and the prices for full or upgrade versions are simply laughable. Microsoft tax, indeed.

[folklore]

Hurley42 said:

You might want to inform universities worldwide about not using Excel for creating graphs of biological (and business school) data sets. It is currently the norm. :)

Huh. Over here in the social sciences, we tend to avoid Excel in favor of general statistical packages (SPSS, Stata, etc) for real work.

I've never had much use for Excel as a tool for scientific work, other than its ability to easily import a lot of legacy file formats and the ubiquitous support for .xls files in other software.

[Hurley42]

Oh, for thorough stats, definitely something else. Excel is horrible for ANOVA or anything beyond basic t tests, but for doing scatter plots with a trend line, excel is used regularly.

[montgomery_burns]

"As a replacement, Microsoft suggests using AppleScript and Automator"
AppleScript and Automator are not cross platform compatible.

[griffman]

No, they're not. And when we spoke to Microsoft, they mentioned this as an actual benefit. Their rationale is that most Mac users are more interested in support for Mac technologies than they are in feature-for-feature parity with the Windows version -- file format compatibility is important, but feature parity isn't as high up the list. Personally, that's not true for me, and based on the reactions here, not true for others. But that's what they told us...

However, given that stance, their lack of support for services is even more glaring.

-rob.

[freddiepingpong]

That's a good explanation. I've been reading reviews for Office for a while now, and people complain about the lack of VBA, but I never fully got the sense of the real problem.
That's really the root of another problem: reviews of programs that support wildly varying workflows for vastly different customers. For example, I generally use Excel for individual, non-repetitive projects; sketching out cost analysis', quickly plotting test data, and simple engineering calculations. The benefits that Office 2008 brought to this workflow are much greater. Chart customization is greatly simplified (no more wizard), and the formatting palette is much more intuitive. The good changes they've made generally fall into a usability category. They can be minor changes in the face of the bad changes for other workflows, but for mine they're great.

[mdawson]

While there are much better programs for scientific/statistical analysis and graphing, palane, none of them are in wide use. Excel is ubiquitous and it is for that reason that a growing number of scientists, engineers and others in data intensive fields have been using it in increasing numbers since the mid-1990s. People in technical fields are not choosing Excel because it is the best tool for the job—much the same could said about Windows :p —, but because everyone has the software.
For instance, in my research group, if I were to use some other software I could not send files to others in my group because they have Excel. We cannot send documents to other research groups within the college because they have Excel. We could not send documents to others throughout the university because they have Excel. We could not send documents to other organizations because they have Excel.
The previous paragraph is proof positive of the problem with Microsoft’s monopoly control over productivity software. I personally use SAS^®^ to do statistical analysis—because the University of Delaware has a license—, but I otherwise use Excel to manipulate, summarize and chart data. If I use something else, everyone else is out of the loop and the one thing Excel has over most of the others is VBA, which is a very powerful tool.
For example, three years ago I developed a software package in Excel that imported worksheets forwarded from the staff at our Cooperative Extension that were generated by their instrumentation. The program would summarize ammonia emission data from poultry houses by scanning minute-by-minute data on the worksheets, computing the hourly and daily averages and totals, chart the summary data and export the results to another worksheet that would be built up over the course of a grow out. Once a flock was sent off for processing, the research group at our Cooperative Extension could send a single workbook to the EPA containing the daily summaries by week over the course of the grow out as well as a graph of daily averages and a graph of daily totals.
In essence 60,000+ data points is reduced to no more than 42 (6-week grow-out) to 49 (7-week grow-out) totals per flock, 42 to 49 averages per flock and two graphs. I cannot think of any other package that give me the ability to not only summarize large sets of data, but to develop software within the application with a user-friendly interface so that the users have no need to deal with Excel in order to process the data. There should be, but that is not the case.

[mdawson]

As Hurley42 indicated, Excel is not the best tool for statistical analysis beyond a simple t-test; and even then you need to make sure the data is normal, otherwise the test will very likely be invalid. But regardless of what program the statistical analysis is performed in, the data sets, summaries and graphs ultimately wind up in Excel because,
* Nearly everybody that needs to be in the loop has a copy of Excel;
* Even if the end-user is not proficient with Excel, they can easily scroll through and switch worksheets to see what more advanced users have prepared for them; and,
* Software such as SAS, SPSS, Strata, Minitab, etc., requires skill on the part of the user.


In all, the person with the technical skills will use the specialized software, but thy will communicate to others through Excel.

[mdawson]

In other words, Microsoft’s spin is that Mac users want Office:mac to be more Mac-like, which is true, at the expense of the ability to collaborate with everyone else using Windows, which is false. I knew Microsoft had a skewed worldview, but d---.
Does Microsoft really expect us to fall for the, “Mac users want to (and can) live in a bubble” argument? Adding AppleScript and Automator support is great, but the vast majority of Mac users that purchase and use Office:mac do so because they need to be able to collaborate with people using Office for Windows. Could you imagine if someone created documents in any other mainstream application on their work PC or received files from Windows using clients/co-workers then came to find that those documents were effectively useless on their Mac? It is one thing when feature disparity occurs with some rarely used or very new feature that has not been widely accepted/adopted, but that is not the case with Excel macros.
Either Microsoft has no clue about the Mac user base or they believe that Mac users are stupid. By the way, I am not shooting the messenger here; Rob is just relaying the BS that was presented to him.

[DJDL]

Once again Bill Gates misses the point.

[mdawson]

The business users that are using Excel to make quick and dirty flat databases are not using VBA. If they had the skills to write a usable macro, then they would use Access, which also comes into its own when scripted. The types of “databases” that people create in Excel are typically simple lists and Microsoft’s Mac Business Unit under that realization added the List Manager in Excel:mac 2001. Generating flat databases in Excel is the fallback for corporate and home users that have no technical computer skills; they are neither inclined to learn how to use a formal database package let alone code a VBA macro. Most such users are in fact far less likely to even be aware of VBA.
As to VBA in Office for Windows, yes, it will be replaced in the next version of Office, but scripting capabilities are not going to be removed. Unless Microsoft wishes to sell little to no copies for the next version of Office—it is already to the point where the suite is so mature that many have no compelling reason to continually upgrade—they will need to support VBA in the next version just as Excel 4 macros are still supported in current versions of Excel. What will most likely happen is that the user will not be able to create VBA-based macros and will instead have to use whatever new scripting language Microsoft chooses to implement; that will most likely be a variant of Visual Basic .Net or C#.
At this time there is simply too much legacy VBA code out there for Microsoft to completely kill VBA in Office for Windows. The uproar from the Windows crowd is the reason VBA support still exists in Office 2007 and Microsoft will need to find a way for VBA coders to easily transition their code to the new scripting language. The MBU has used the excuse of the Intel transition to leave Mac users in the cold, but quite realistically, the transition to Xcode should have occurred for Office:mac 2004, thus making the transition to universal binaries less of an issue now. I mean we are on what, the third version of Office:mac for OS X?
Microsoft has chosen to cut Mac users off at the knees so the “push in that direction from Microsoft” you mention is a push off of the collaboration curve. The weak support of VBA on the Mac up till now was bad enough, but now Excel:mac is completely useless in mixed platform organizations where macro-enabled workbooks are commonplace.
As to AppleScript, Rob hit the preverbal nail on the head when he stated that AppleScript is not like other languages. Despite having vocabularies that differ to varying degrees, languages such as (compiler) BASIC, Visual Basic/VBA, FORTRAN, C/C, Pascal, Modula-2, Javascript, et al., share a common coding style. Therefore, once you learn one of those languages, it is very easy to transition to writing code in any of the others. Learning AppleScript is like learning SAS^®^ in that its coding structure is very different from that of the core high-level languages. AppleScript is a verbose language much like COBOL and it therefore takes a little more effort for an experienced programmer to transition to coding in AppleScript. Like my SAS^®^ professor told us at the beginning of our first course, having extensive programming experience can be a curse when learning SAS^®^ because it is so different; the same can be said of AppleScript.
Also, as Rob mentioned, AppleScript is post-processing scripting language. The area where VBA shines is in its ability to control the elements of a given VBA-enable application as well as modify and manipulate content. VBA Excel, VBA Word, etc., all contain the core VBA library as well as extensions for their respective applications that allow the programmer to control document objects, the documents themselves and even application objects, such as the menus Rob mentioned. I have in fact created a number of custom workbooks with custom menus, custom menubars or just hidden the Excel interface altogether in favor of the user interface I create using userforms. AppleScript cannot do that.

[mtackie]

Microsoft has always crippled their apps with respect to the Windows equivalents. the first time I used Excel for Windows, I could not believe how far ahead the debugger for VBA was. Recently, they have become more blatant: no more WMV plug-ins for Mac web browsers, no more Virtual PC, no more VBA. Our alternatives are (a) to upgrade to an Intel mac, run Parallels or some other virtualization software on it so that we can run Windos Excel (b) switch to something like OpenOffice. Unfortunatley, OpenOffice is not quite ready yet (I cannot figure out all that UNO stuff). So I am stuck with my G4 running 10.4. Thank you, M$!

[juanca456]

FYI
http://www.neooffice...en/features.php
It's free