I was lead developer for a company ten years ago who developed tools for industrial companies. We had a steel rack manufacturer approach us with a panic inducing spreadsheet of the calculations they needed. It was 8 very full worksheets and included everything you could think of, including seismic data by zip code.<p>To build this proper was going to take our small team at least a couple months. The sales people didn’t like this. I had an idea however to extend a SpreadsheetML parser I’d written a few years prior with a formula evaluator. I had a prototype working within a couple days, I reimplemented a large number of Excel functions warts and all, and since Excel saved all the last computed values along side the formulas it was easy to automatically test. It was the first project that really taught me the value of unit testing.<p>It was a fun project and took around a month in the end, which was still over the amount of time sales had given us. The client actually sent us a fair number of revisions to the spreadsheet such that had we built it out any other way would have been a major project, but was as easy as swapping the spreadsheet the tool read. I left the company a few months later but I was sad to hear from coworkers they never did anything else with the tool. I thought it was a really neat hack.
my typical experience with these kinds of things: I start looking at the source code, and the code is actually simple and short, the logic is easy to follow (make a grid, allow and process formulas in cells, display the grid and some additional edit-mode display if you are editing a cell)... but then I start seeing dependencies, references to other frameworks and multiple languages, libraries... and all that looks so confusing! the dependencies require at least an order of magnitude more knowledge to be understood or used effectively than what we are being shown in the post; that's the really tricky part to me. don't mean to criticize that, those are probably very powerful tools that in most cases you want to know about and use (if you are working in that specific environment), but it's like... are those 100 lines of F# even that important? writing your own excel sounds nice, but I feel it's more "how to glue a bit of F# logic to a web-compatible UI" (well, yeah, one could argue those are really the same things).<p>> "The final spreadsheet application is quite simple"<p>Is it? I easily understand the logic of the F# code, but I couldn't make another "similar" application so easily unless I was just copying the dependencies. I wouldn't really know what I'm doing, maybe it's not so simple!<p>(this isn't meant to be a criticism to the article itself, I just wanted to share this uneasiness I get when checking some code I don't know much about that's presented as "simple"/"short"/...)
Fantastic example of how to structure a real life (ish) application with functional programming. I don't know any F#, but I can see how to apply this to imperative languages and make them easier to debug
I implemented a React component with a subset of Excel features and additional customisation features: <a href="https://github.com/iddan/react-spreadsheet" rel="nofollow">https://github.com/iddan/react-spreadsheet</a>
Thanks for sharing. I'll try to write an equivalent code using Rust for learning purposes. Since it has algebraic datatypes too, it should be fine.