“if it’s not there, get off your ass and make it.”

Exactly.

Ever tried using OOo’s object model documentation? OOo *MIGHT* be more programmable, but it can take hours if not days to hunt down example code (because there ain’t any documentation) for object model operations that would take a few seconds to read about in Excel/VBA online help and maybe a minute or two to code.

Nein. I also somewhat preempted this in my comment, and completely agree. I programmed some BASIC many years ago (very simple stuff), and then a little bit of C++, but Excel VBA is the environment I have done the most with. Even then, I’m not a developer; I hack pieces here and there to get my job done, as a secondary or tertiary necessity.

To more strongly agree with sentiments about the ease of EVBA programming, I could never have developed what little programming acumen I might have working with Java to develop OO.o. Period. While they’re not necessarily well written all the time, and seem to be less well written in 2003 than in ’97, the help files in Excel VBA IDE are wonderful and nicely accessible (place the cursor + F1 = nice). Beyond that, there is loads of overhead taken care of in this environment.

I consider Excel to be the highest-quality product Microsoft has available. Yes, that’s very biased. I don’t have a problem with that.

@Jon Peltier

Daniel – Are you saying I should get the OO source code, hack away, then recompile? Deployment will be a bit more involved than emailing a file then, won’t it?

I’m not saying OO.o (nor Excel, nor gnumeric) is more easily programmable. I see rhetoric like

OpenOffice cannot match Excel’s programmability. If you want Open Source, fine, but if you want Excel’s capabilities, cowboy up and get Excel.

and I think we can do better. It tastes a little like FUD. We shouldn’t conflate ease or accessibility of programming with inherent programmability.

But, back on track here, the complaints about how this freebie wouldn’t work in OO.o are abominable. No doubt. Too many people seem to miss the point that there’s nothing wrong with closedness, and there’s nothing wrong with wanting to make money. Statistics purists should probably hit R instead of any spreadsheet program, anyway. You could even go so far as to use Sage, which has an interface to R but also to tons of other applications, as well as a Python (and Cython) core. Don’t bitch because a product made specifically for Excel isn’t available for OO.o; also, don’t bitch because a Firefox extension isn’t available for Opera. This actually cuts against the underlying philosophy of open-source projects: if it’s not there, get off your ass and make it.

In short: I’m a great fan of Excel, and its VBA implementation; but dogma for or against it is at least confusing, if not injurious.

Unfortunately for users of anything that isn’t Excel, Excel is currently so dominant it would be hard to justify porting an Excel add-in to another spreadsheet app. Novel OpenOffice has pretty decent VBA support, and its improving all the time so its getting more realistic.

I’d suggest which is the most programmable is less important than which is the most programmed. (From which we could infer which is most programmable in the real world.)

I use OOo and gnumeric on everything except my dev machine and I still havent ported any of my code or add-ins, and I have been meaning to for years.

Ever tried using OOo’s object model documentation? OOo *MIGHT* be more programmable, but it can take hours if not days to hunt down example code (because there ain’t any documentation) for object model operations that would take a few seconds to read about in Excel/VBA online help and maybe a minute or two to code.

Sun had done a demonstrably horrible job documenting OOo’s innards, and the OOo community hasn’t contributed much support in this area. This is one of F/OSS’s greatest weaknesses: the belief that providing source code reduces or eliminates the need for proper documentation. OOo programmability is an excruciating example. Note: these comments DON’T apply to gnumeric, which has much better docs than OOo.

OpenOffice cannot match Excel’s programmability. If you want Open Source, fine, but if you want Excel’s capabilities, cowboy up and get Excel.

I’ll give you that VBA is Excel’s edge, and that OO.o isn’t a giant killer (slow, for starters). I use gnumeric.

I would offer, though, that OO.o, by virtue of being open-source, is demonstrably more programmable than Excel. VBA provides a wide palette of hooks; OO.o, via Java, provides every single hook plus the capacity to create your own.

Of course, for daily usability, VBA, especially due to its integration and IDE, is superior for most tasks you’d want to program in a spreadsheet.

As for the OOo advocates, they don’t understand why VBA is Excel’s greatest asset. OTOH, OOo Calc is much more of a 3D spreadsheet than Excel. Ever needed relative worksheet addressing? Try doing that without VBA or XLM in Excel. Whereas the capability is built into OOo Calc’s addressing syntax. All depends on what your ‘must have’ feature happens to be.

Well, dummy, it uses Excel’s VBA capabilities to do its magic. Why can’t it use OpenOffice’s VBA capabilities? OpenOffice cannot match Excel’s programmability. If you want Open Source, fine, but if you want Excel’s capabilities, cowboy up and get Excel.