Excel Functions in F# Language(sharpcells.com) |
Excel Functions in F# Language(sharpcells.com) |
But, being more of a Lisper, I've already subscribed to Acceλerate for Microsoft 365[1]. It's basically a full scheme available in Excel with VSA (Visual Scheme for Applications - nice play on VBA to dupe the unaware ;) ). It has a full REPL and an editor and also creates UDFs. It is Excel's new Lambda on steroids.
I'll have to try Sharp Cells. I've played with J[2] and some Excel tie-in scripts, but it is not integrated as nicely as Sharp Cells or Acceλerate.
I agree that the non-portability of such Excel extensions is a showstopper for many use cases.
When you use Sharp Cells the F# scripts are embedded with the workbook when you save so sending the .xlsx will work for the recipient provided they also have Sharp Cells installed. For many workbooks the free tier would be sufficient for use.
If the user doesn't have Sharp Cells the functions won't load and the results relying on Sharp Cells UDFs will be replaced with `#NAME?` errors.
But this would never fly for us. The pricing model could not be sold to management.
What would work is if it was something like $5k for a year of updates. We're on 365 so office's constant updates would force us to upgrade every year. But management would not feel like they're renting something they would rather own.
We have a spreadsheet that takes information from online orders into input cells. Then it has lines that if they calculate a qty of 1 or greater get consumed by CAM software. The product then gets sent to the appropriate machining center. Not a single line of VB. There are a few things that I could extract into custom formulas that would remove pages and pages of Excel formulas. However the entire point of the Excel setup is so that product experts not programmers can edit them.
We currently have F# in our internal tools. We have a couple of CRUD apps on the SAFE stack. A few ETL tasks in F#. The bug count seems to be much lower when using F#.
There is some legacy stuff in PHP, JAVA and C#.
Then we have an online store in C# but that is just using an open source tool NopCommerce. I couldn't recommend that highly enough. It has been amazing compared to everything I've worked with in the past.
I work with data warehouses, but I'm really jealous of the way our Finance team uses some abysmal plugin to directly query our GL from inside Excel - building something like that the can make the contents of a modern data warehouse available to Excel users has always been a holy grail for me.
My hunch is that exposing free-form SQL in Excel doesn't work, but something more like structured metrics (something roughly like dbt metrics) could potentially work? And tooling like this is probably what I'd want to prototype with.
https://learn.microsoft.com/en-us/office/client-developer/ex...
https://learn.microsoft.com/en-us/office/troubleshoot/excel/...
Sharp Cells' aim is to make it easy to use these APIs from F# so you don't have to worry about P/Invoke, manual memory management, dynamic .NET assembly loading, etc. to just write custom functions.
I quit that job because the extensibility story for Excel was so painful (but they had good business reasons for being in the space), sigh.
Limiting (let alone this severely) a number of functions a developer can introduce and locking them in having to pay recurrently just to overcome this limitation and keep their code working is insane. I believe this dooms the product to be extremely unpopular. This way people probably won't even invest time in giving it a try.
Real-Time Data Sources sound like a thing which can be a premium feature. Unlimited UDFs and Unlimited Commands don't.