Comment by microcolonel | Hacker News Reader

Comment by microcolonel | Hacker News Reader

Parent Full thread

Calc's problems run deep. Every other release breaks the find function or something similar in a way that literally crashes when editing my company's massive golden workbook.

Nonetheless it is still usable. When we have more scale, we'll probably just implement a subset of ODS as an import for a custom spreadsheet program that I've been working on in my more-free time (looking to make explicit loops/tables of intra-row and previous-row dependent expressions, enabling lazy sequences [or just sequences with length defined by downstream users] and more straightforward static compilation w/ LLVM or similar).

ODS is pretty bad, especially the way LO writes it. For example LibreOffice adds like 50 styles to your ODS files, even empty ones, every time you save; and one of them is called "Default", even though ODS has an explicit mechanism for default styles that LibreOffice recognizes. I could go into all the levels of hell in LibreOffice-generated ODS files (not to say others don't have their own flavour of hell). LibreOffice, and I suspect most ODS generating programs, routinely generate schema-invalid ODS files for a good reason (boolean value cells with integer cached values, which are essential).

I think my new legacy-optional spreadsheet can be pretty killer, and I hope to bring it to the masses at some point.

In Excel, intra-row and previous row are better handled by DAX (PowerPivot), than the grid as such. This is, of course, unique to desktop Excel. If you are at the point where you are building your own engine for that sort of thing, and have a “massive golden workbook”, wouldn’t SSAS make more sense?

We have already built our own compiler, it's just that a lot of work has to be done to deduplicate expressions (in part because references are stored in A1 form, this is also part of why it takes about 15 seconds to unzip the ODS and parse the XML), and even more to consolidate intermediate cells, and dirty prologues/epilogues on tables don't help (because they often mean the first cycle will be odd).

With explicit cycles, most of that work can be avoided.

Furthermore, explicit row iteration means that you can attach reductions to the generator based on the range (i.e. you have a GEOMEAN and a SUM with a statically known range), which often means you don't need to store the results of the iteration, and that also you don't have to compromise between AOS/SOA storage for reductions that can be run with the generator.

Static primitive, option, and union types are also a goal. You can think of standard Excel/Calc values as a tagged union Option type.

Also relying on Windows or macOS to edit our core sheet is kinda out of the question. None of our developers even run windows, and the majority don't even run macOS. Two of us came from a company that did that, and the Excel virtual machines were always finicky there.

Reply on news.ycombinator.com