
Write your own Excel in F# (2018) - eDameXxX
http://tomasp.net/blog/2018/write-your-own-excel/
======
donatj
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.

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.

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.

~~~
flashgordon
Damn It. Where are _these_ problems today? Or is it a matter of just choosing
between getting paid vs passion? As a hirer in a FANG, I feel ashamed at how
much we put some of the smartest and hard-working people to work on yet-
another-crud-rest-api.

~~~
ultrasounder
I work at one of those _rare_ manufacturing companies here in the bay area(pay
isn't anywhere close to what FAANG median is).We tend to use Excel for
everything from manufacturing quality Pareto charts, SPC charts and its a Big
mess.All I hear from Big tech enterprise tech is IoT and datalakes but no
immediate solution that aggregates all this data in manner that can be
consumed by various LOB Apps that can do things with the data. So I am in the
process of building one right now. But You are right. FAANG along with every
other unicorn is running after the NBT, wherein there is so much more to
automate in well established Non-big tech(Dino tech) like P&G case below.

~~~
perl4ever
You can do nearly anything in Excel/Office with VBA, from automating manual
processes, to BI reporting, to gluing together any and all data sources, it's
just that CS type geeks _hate_ it and refuse to learn it.

Being limited to only Office for a few months has not made me think "how
horrible it is not to have real tools", but rather "how amazing is the amount
of money and effort people waste on 'enterprise solutions' that are both
orders of magnitude more expensive and inferior".

~~~
haspok
On the other hand I once had the enviable task of converting a spreadsheet to
SQL - minus the data import, the calculations in Excel ran for hours, after
the conversion the stored procedure took about 2 minutes to run.

And this was something that the business had to do daily - you can imagine how
effective it was to start the calc in the morning, have it hog all your CPU
for hours then get the results after lunch if you were lucky and did not have
to restart the whole shebang.

Yes, Excel is brilliant at communicating with business users and getting stuff
done quickly. But it does not scale and has some problems with the normal
software development flow - just try to put your Excel files in version
control and you'll see what I mean...

~~~
perl4ever
I am inclined to think that 99% of the time people blame a tool for being
slow, there are very, very basic issues in how they use it. And often people
are just not motivated to solve those issues if they don't like the tool
anyway.

I was handed a T-SQL script once, that produced a report on a few thousand
items in a document management system. I was asked to use it to get statistics
on a few hundred databases with millions of documents each. Which would have
taken a few centuries at the speed that it ran. So I looked at it and realized
the core was a procedural loop, which ran a separate SQL query for _every row
of output_. Once the procedural part was replaced with one SQL query, it ran
_thousands_ of times faster and then all that remained was to replicate it to
a bunch of databases and build the report in parts.

My rule of thumb is that if anything is too slow these days, it's because
something is terribly misconfigured or something is severely wrong with the
algorithm.

------
slx26
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).

> "The final spreadsheet application is quite simple"

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!

(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"/...)

~~~
aardvark291
I remember feeling this in regards to some early "rapid application
development" software in the 90's (Visual Basic or Borland Delphi or
something).

"Look how easy it is to make a text editor!" \- Drag the "text editor
component" over a blank form. Look how easy it is to make a web browser! -
Drag the "web browser component".

Or, maybe it was in PHP, "As an example, here's code to format an integer as
Roman numerals." Oh, that sounds interesting... Expecting a cool algorithm,
then discover it's (for some reason) a standard library function.

~~~
empath75
Why solve problems other people have already solved?

~~~
willtim
To quote Feynman, "what I cannot create, I do not understand".

~~~
jister
So in order for you to develop a payroll system you first need to know how to
create a database?

~~~
elyseum
Well, to write a high performance payroll system with lots of concurrent users
it helps a lot to know how the database you’re using works internally.

------
iddan
I implemented a React component with a subset of Excel features and additional
customisation features: [https://github.com/iddan/react-
spreadsheet](https://github.com/iddan/react-spreadsheet)

------
jeanmichelx
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

------
xixixao
How does F# on Fable compare to Elm and Purescript, and how is each doing
these days?

~~~
tpetricek
I don't have much experience with Elm or Purescript, but one nice thing about
F# with Fable is that it's a pretty flexible language that let's you do things
in many ways and integrates well with libraries that use different styles.

For example, the Excel blog post is using virtual-dom directly (without higher
level libraries like React) and getting that to work was a few lines of simple
code with one mutable variable, but that's all you need to get a nice
declarative Elm-style architecture.

------
Nelkins
Fable/Elmish is a cool combo, I'm writing really simple admin tool for work
with it now and really enjoying it.

------
enz
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.

------
aardvark291
How does F# compare to OCaml or Haskell?

~~~
fsloth
F# started as Ocaml for .Net and then added all sorts of pragmatic language
constructs. I'm not an expert - F# AFAIK misses some of the higher level type
theoretic stuff, but you can write 'basic' Ocaml that would be isomorphic with
F#.

The key high level features that F# inherits from Ocaml is a succint syntax
due to type inference and 'if it compiles it's bug free' development.

~~~
lolinder
Does "if it compiles it's bug free" actually work in practice? I've heard a
lot of advocates for Haskell and Rust use similar lines to this, but it seems
to me like it can only be true for a limited subset of all bugs. Elm's "no
runtime errors in production" claim has a more reasonable-sounding scope.

~~~
fsloth
Sure, it's limited to a subset of all bugs but with a proper typesystem the
category of bugs you can remove from code by just encoding the semantics and
algebra into the types is quite large.

So if you know how to formulate the problem so it leans heavily on the type
system, you can implement something like a binary tree container, and presume
it is correct when it compiles.

Following the same parameters bestows rest of the codebase with this
robustness.

See for example the ACM article "Ocaml for the masses" by Yaron Minsky of Jane
Street for very lucid practical examples
[https://queue.acm.org/detail.cfm?id=2038036](https://queue.acm.org/detail.cfm?id=2038036)

------
rishav_sharan
If anyone is interested in gamedev in F#, try Xelmish. Its F# + the elm
architecture + monogame

------
ape4
Value of this cell = formula which may depend on other cells

------
jimbob45
The coolest part is that it's in F#. Add that to the title. How many F#
samples do we get around here anymore?

~~~
melling
F# was in the title when I upvoted. Someone changed it.

~~~
marmaduke
That's pretty yucky since anything written in Rust gets to keep that detail in
its title

~~~
dragonsh
Rewriting code in rust is new fashion, so for the purpose of publicity anyone
writing anything in Rust will put the language name in headline.

But I believe this trend started with Go lang and later picked up by rust
community.

It's nice to see some F# code. I am happy a lot of new programming language
innovations happening, I did not pick up rust, because the programming
paradigm is similar to other programming language with focus on memory safety.
I will try F# may be later, these days more busy with learning lisp as many
people recommend it to become a better programmer even though it's not popular
as Go and Rust.

~~~
FridgeSeal
> But I believe this trend started with Go lang

I thought it started with JavaScript, there was a while there where everything
was getting done in JS, and that’s arguably more egregious than Rust.

~~~
dragonsh
You might be right, when node js was becoming popular.

Personally I observed it only when I myself started programming in go, at one
point in time in the early 1.0 version.

