Hacker News Reader

Comment by ancarda | Hacker News Reader

+1 for Pages. I once sent a .pages document to a friend on Linux. I was genuinely surprised when he could read it. Turns out .pages is actually a zip file, that when extracted, has a PDF inside.

Pages has always scaled fine for me, however Numbers will choke on a gigabyte-sized CSV. I tried to, import the US census data into it. I couldn't get Numbers to work. It crashed every time. Microsoft Excel could just about cope but was struggling to scroll or filter data. Eventually I gave up and threw it into MySQL. The right tool for the job.

View on HN

> Microsoft Excel could just about cope but was struggling to scroll or filter data. Eventually I gave up and threw it into MySQL. The right tool for the job.

Although Excel has since been corrected for this use case[1], it isn't even the right Office tool for the job. That's what they created Access for.

[1]The SQL Server team built PowerPivot for Excel 2010+, which basically imports your data into a SQL db that gets embedded into the Excel file and transparently queried from Excel proper. Runs smooth as butter, and pacifies the Excel purists who refuse to lower themselves into using Access (I've worked with several of said purists).

Access is not available for Mac though.

You're correct, and Excel for Mac also doesn't support the PowerPivot addon either. However, that still doesn't mean you can fault Excel for barely being able to cope with a use case it isn't designed to support. The fact that it can handle it at all is a testament to the versatility of the program, not the other way around. It simply isn't the correct tool for the job, and shouldn't be faulted for subpar performance in a scenario it wasn't designed for.

Writing code in Word is completely possible, but would you fault Microsoft for the ensuing bad experience? You can also use Eclipse for writing a resumé, but would you fault it for not supporting that use case very well?

How much ram do you have? Not an excuse for their programmers though.

I always understood it to be a feature of Excel that it couldn't cope with larger datasets.

It means you are forced to consider buying an expense Enterprise SQL license once you are using it in earnest. If it wasn't for Excel chocking on 5million rows I'm convinced most businesses wouldn't bother with databases at all.

Well sure, if Excel did X then business wouldn't need another program to do X, and this is true for any value of X.

Your comment is a bit like saying "Most businesses wouldn't bother having a cafeteria if only Excel could cook meals."

Excel was never designed to replace a database and the fact that it can't isn't some evil plot by MS.

>> "Most businesses wouldn't bother having a cafeteria if only Excel could cook meals."

This part is tongue in cheek, but true. There are businesses out there, where excel is used for everything, including many things it should never be used for. Seriously powerful app. Seriously (ab)used.

I don't hate Excel, but I hate the "craplications" hare-brained power users create.

16 GB. That was enough to load it into RAM, it was a matter of the "right tool for the right job". MySQL handles large datasets easily, probably because it's not trying to display all the thousands of columns x millions of rows at once.

I've found the same to be true for editors. Most text editors have struggled to open large log files (500+ MB) whereas cat can open a file of basically any size.

I've had a similar experience with editors, good old vim and less works but most other editors will crash or become unusable as log sizes increase.

Of cause, for parsing logs a few well thought out awk commands combined with sed, sort, unique and other *nix utilities usually beats everything else in my experience.

Reply on news.ycombinator.com