[mdlug] What Intel Giveth, Microsoft Taketh Away

Aaron Kulkis akulkis3 at hotpop.com
Sun Nov 18 21:26:50 EST 2007


Clinton V. Weiss wrote:
> On Nov 17, 2007 8:34 PM, Michael Corral <micorral at comcast.net> wrote:
>> 2007-11-17, Monsieur Clinton V. Weiss a ecrit:
>> So let me get this right. You're complaining that OpenOffice was not
>> as robust as Excel in opening a complex *Excel* spreadsheet with tons
>> of embedded *Excel* formulas, and this for a spreadsheet that was
>> created with a library (JExcelApi) that was designed to "read, write
>> and modify Excel spreadsheets" (<http://jexcelapi.sourceforge.net/>)?
>> All I can say is: wow.
> 
> I'm complaining that an open source alternative that claims to support
> Excel and it's formulas shouldn't need to be so inefficient.

Considering that even the  internal FORMAT of all office
files is trade secret, and oftentimes, not even well
documented within Microsoft itself, you expect a
reverse-engineered implementation to be just as efficient
why, exactly?


> None of
> the formulas used were custom, they were all standard Excel formulas
> such as vlookup, sum, etc. etc.

Yes, but who knows WHAT Microsoft's algorithms in Excel
look like?  Of the times that I've seen code snippets from
Microsoft released for public viewing, it's looked pretty
cludgy...which is often-times fast in particular instances,
but can lead to complete lockups in others, because of
lack of error-checking, etc.

> 
>>> I'm a huge fan of open source, however, I'm also a huge fan of using
>>> the right tool for the right job.
>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> Then why didn't you use a library that creates *OpenOffice* spreadsheets
>> instead of one that creates *Excel* spreadsheets?? That would have been
>> the proper way to use OpenOffice. Your complaint would be like someone
>> complaining that Excel doesn't open QuattroPro spreadsheets as fast as
>> QuattroPro does.
> 
> Because the spec asked for Excel spreadsheets that could also be
> opened in OpenOffice.  Therefore .xls files are the answer.
>

So the OpenOffice people are supposed to be super-heroes of
the programming world to fulfill the expectations of someone
at your place of work who wrote a ludicrous spec?


>>> OpenOffice, as much as they'd like
>>> to claim, is not yet the right tool for heavy spreadsheet usage.
>> Sure it is. And many people use it for that every day. You just weren't
>> using it properly. That's your fault, not OpenOffice's.
> 
> OpenOffice was being used with one of the intentions it was designed
> for: to open, read, and manipulate Excel spreadsheets.  My only
> complaint is that it was so damn slow and inefficient.

Well, that's what freakin' happens when you're dealing
with file formats that are trade secrets, and have to
be reverse-engineered .... lots of code kludges get into
the file import filter, because the spec itself is most
likely kludgey (and if you want proof, check on the
debate about the misleadingly-named "openXML" kind-of-
but-not-really-a-spec which is nothing more than an
xml-ization of the Office internal formats.

It's clear as mud, with takes like <DoLikeWord95>,
with no explanation or definition of how Word95
supposedly did it.

> 
>>> OpenOffice is *NOT* Excel.
>> Exactly. :) And that's a good thing. I sure wouldn't want OpenOffice
>> to calculate 65535 as 100000, as Excel 2007 does:
>> <http://it.slashdot.org/it/07/09/24/2339203.shtml>
>> Better hope your Excel formulas don't calculate that. :p
> 
> If they do and a client points it out to us, well, I've already
> collated all the documentation necessary to say "we can't do anything
> about it." :)

We can't do anything about it until Microsoft stops keeping
secrets about how YOUR DATA is stored by their software.

> 
> I'm not looking to cause a religious war or flame thread here, I was
> just backing up Brian Hurley's link with real life experience. (
> http://blogs.zdnet.com/Ou/?p=480 )

Your complaints are PRECISELY the argument against
secret file formats -- why do you find any of this
in the least bit surprising?

> 
> Clinton
> 






More information about the mdlug mailing list