Show HN: I've built a C# IDE, Runtime, and AppStore inside Excel (querystorm.com)
The project is called QueryStorm. It uses Roslyn to offer C# (and VB.NET) support in Excel, as an alternative to VBA. I've posted about it before, but a lot has changed since then so figured I'd share an update.
The current version includes a host of new features, namely a C# debugger, support for NuGet packages, and the ability to publish Excel extensions to an "AppStore" (which is essentially a NuGet repository). The AppStore can be used by anyone with the (free) runtime component.
Another great addition is the community license, which is a free license for individuals and small companies to use. It unlocks most features, but it isn't intended for companies with more than 5 employees or over $1M in annual revenue.
I would love to hear your feedback and am happy to answer any technical questions about how QueryStorm is implemented.
182 comments
[ 4.7 ms ] story [ 253 ms ] threadLast I checked, admittedly a couple of years ago, starting with F# wasn't absolutely trivial.
Therein lies the problem. The language doesn't have much marketshare, and few champions.
I just finished reading Scott Wlaschin's Domain Driven Design for Functional Programmers and it's an incredible, batteries-included guide that goes from "hello world" to "and here's how you use it in an organization" in a few hundred pages.
I wish I had been exposed to it about a decade ago. Incredibly easy to follow and well-explained.
Why is there so little noise in F# land? I have no data, but I can guess that the language is so unproblematic that everybody is just happily coding instead of explaining how to fix something. It’s also not very good at guis so there is usually nothing visual to demonstrate.
AFAIK F# is on quite solid foundation, as there is the F# foundation that would keep ball rolling, so to speak, were Microsoft to renounce the language.
I have no idea what the marketshare is though. On Tiobe (https://www.tiobe.com/tiobe-index) it seems to be nearly on par wit Scala and much more popular than Haskell or Ocaml.
According to JetBrains developer survey, an amazing 3%.
https://www.jetbrains.com/lp/devecosystem-2022/csharp/
All of the GUI stuff is missing of course. I would not advice to implement a GUI on top of F#.
The main feature of F# imo is it's succint type system where one can wrap everything in a type without much bureaucratic cost, but in a way that makes program structure so much more obvious. "If it compiles it's correct" is prety much how it goes.
They already have to use C# no matter what, given the GUI and database frameworks.
Adding C++ or PowerShell into the mix might happen, due to the frameworks and workloads that require reaching out to them.
While adding F#, even if more expressive, it barely makes sense from business point of view.
It isn't as if a mixed C#/F# codebase brings the same value as doing Python/C++.
Also to note that while F# team has pivoted into trying to make F# attractive to data science, their employer is one of the reasons why CPython is now taking performance more seriously.
F# code is much more reliable and requires much less people to write. Isn't this good for business?
The only problem with F# is it's not always immediately readable to those who are not familiar with it (so it's harder to find the people to hire), isn't it?
I just wonder how much harder it is to teach a random person (without even a rudimentary programming skill) to code F# than to teach them C#.
"It isn't as if a mixed C#/F# codebase brings the same value as doing Python/C++."
I think it depends on industry and domain what the value add specifically is? To me it would totally make sense to have small, succinct business logic module in F# that talks natively to a verbose chunk of C# wpf for instance.
"Also to note ... CPython is now taking performance more seriously."
Personally I would not hold Python isomorphic to F# on any architectural level, the former not having the typesystem of F#. IMO the whole point of F# is the wonderful typesystem, immutability first, combined with full .NET ecosystem.
On the other hand I would not try to use F# for the stuff I use Python for - so trying to take Python head on does not sound like a super good strategy.
I guess F# will languish in the "few percenter limbo" in the best case. But it IS a really nice language :)
- fsharp's big selling point is that it runs on dotnet - most FP ideologues run screaming from M$, and there are other, better (subjectively), more-active FP langs that do many of the same things, such as OCaml and Haskell - most dotnet shops are "csharp or die" and getting fsharp adoption is more or less an impossible task for cultural reasons
I support fsharp and generally like it, but I'm not reaching for it for net-new stuff that doesn't already have a dependency on dotnet. $0.02.
This can be also a blessing that makes the F# community quite pragmatic rather than dogmatic :)
FP makes pragmatic sense, it's not an ideological concept.
As for being better, F# is better on the language level, but sadly sucks on the tooling effort for .NET frameworks, that Microsoft is willing to spend on it.
One small point: on your webpage the "Try QueryStorm out" button on the "Start a free trial" panel just points to: https://querystorm.com/csharp-in-excel/ rather than the generate key page.
I've built an Excel-DNA based Add-in (https://www.excelpricefeed.com/) and distribute it via an installer built using Advanced Installer. It works well, the only real pain point is the the user has to find out which version of Excel they have installed in order to choose the correct download (32 or 64 bit).
Great work!
This seems far more useful!
Also, I would be super proud if I'd created this. Excellent work!!!
I am also aware of a commercial product that offers a .net IDE to be embeded into your software, though I never tried it: https://www.alternetsoft.com/products/scripter
The combination of a spreadsheet, database and data scripting runtime would be extremely powerful.
This is where Airtable, nocodb and baserow are candidates.
I worked at a company that used gridgain with Excel as a cluster to process models on lots of servers.
I suspect there's a lot of low level Windows integration details about how to integrate with Excel. COM objects and DLLs.
Why is integrating with software so difficult? Very few people know how to do it.
How you design software that is extensible?
Atom was extensible and VS Code is less so.
Why has nobody integrated the web browser with QT? So we can browse into a Qt application. So you can create desktop widgets and canvases with Qt from Javascript? That way you could ship desktop software and arbitrary integrations to software.
I feel it's because of inherent conflict of interests and priorities. A software product can provide services to the user, or provide services to other programs. It's rare to see one that does both, because the two goals seem often at odds.
Say you're writing a software component for other programs to use. You probably have some specific programs in mind, some of which are end-user-facing. In this case, you may not want to spend resources on developing user-facing UI and features that make your product usable stand-alone - you'd likely end up competing with your own customers.
Say you're writing user-facing software instead. You want to own the entire user experience. Mixing UI, user interaction and the "business problem"-solving code together lets you work faster. Also, you don't want to make it easy for anyone to integrate with the core of your software, because that would be inviting competitors to own the user experience while using your own backend, ruining all kinds of marketing shenanigans you'd rather play on your users.
I don't like this, but I see there's a mix of both reasonable and greedy reasons why software isn't developed with integration in mind.
The major exception here is when the platform on which the software runs encourages, insists on, or demands the software to allow for integration. Windows does that to an extent with COM / DCOM. Emacs does that by its nature. But it's only moving the problem one level up - e.g. Microsoft environment can't integrate well with Apple environment.
https://www.microsoft.com/en-us/microsoft-365/roadmap?filter...
I also have a vested interest as one of my software products is an xll Add-in. Any further details from Microsoft would be most welcome, thanks.
He declined several approaches from ex-Borland people working at Microsoft, before reaching that point.
https://behindthetech.libsynpro.com/001-anders-hejlsberg-a-c...
In Excel working hard to make addons possible and trying to foster an ecosystem of users sharing expertise is a focus as well as community building and smbs.
Taking a cool community project and doing it ourselves would shooting our selves in the foot.
More than once I didn’t do things or work in features for that reason.
Again not because Microsoft is your friend but because it’s in our business interest.
I don’t speak for Microsoft or Excel and am just a developer/hacker ;)
(not that I'm arguing for trust that would, as you say, be misplaced, but if my feeling is correct then the Excel org's englightened self interest can diverge from the mothership's self interest more than other divisions can, which makes the calculations as to what your management is likely to decide notably different)
Apps (where Office belongs), DevDiv (VS, .NET and such), WinDev (Windows, C, C++).
All of them used to compete quite a lot among themselves.
No idea how it looks like nowadays with all the business units, but I get a feeling that WinDev vs DevDiv is still a thing.
Which in turn leads me to think there should be a way to create a virtual Range object in VBA that isn't really in a sheet (or a VirtualRange object that is similar enough to Range to make it work for most purposes). If one were to refactor Range entirely (not suggesting that), it seems like the issue is that the Range object actually encapsulates two different data representations into one jumbled up object: (1) cells in a worksheet with properties such as style, fill, value, etc. and (2) a traversable quasi-array data type with useful methods such as offset, rows, columns, etc. Those two things often line up, but not always.
Anyway, I probably spend too much time thinking about Excel :-) </rant>
But still sucks having to do requests in VB.
https://learn.microsoft.com/en-us/office/dev/scripts/overvie...
https://learn.microsoft.com/en-us/office/dev/scripts/develop...
So can people upload their code snips to the appstore such that, say, a marketing data analytics person with no coding experience can pay to get 'buttons' to run queries that are relevant to their needs?
like the salaries example, for example, I used to spend a shit-ton of time educating a CFO on AWS spends in excel.
If I could have a code snip 'button' to use some AWS-CLI creds to pull results directly from AWS asa "CFO BUTTON" and set them up with an easy export to an XLS - and then let them build their own dash to their choice that would be cool.
I havent looked at Cloudability in quite a while, (know the founder) -- but giving a CFO-type an excel button... Every CFO can navigate excel. so they get an invisible tool that empowers them, and relieves stress on the Ops team...
You create a project that defines some custom functions, ribbon commands, context menus, shortcuts etc... and then publish it to a store. Then anyone who has the QueryStorm Runtime (and the url of the store you published to) can install it through the "Extensions" dialog.
I haven't yet set up the ability to charge for packages but I plan on offering this. I first need a community of users, so didn't focus on charging yet.
If you'd like some help setting up something like that AWS scenario, reach me via email: antonio [at] querystorm.com, I've done several such integrations already (Google analytics, Monday.com, TSheets, Google drive).
"VBA is a bit (a lot) behind the times and Microsoft isn’t planning on upgrading it. Instead, they’re offering a sandboxed JavaScript environment called Office Scripts."
Microsoft - Just swap VBA for Python ffs.
You can version control the code you write with QueryStorm, to an extent. There are basically two kinds of apps you can build with this: extension apps (where you build general excel functionality) and workbook apps (where you automate a particular workbook).
The code for extension apps is stored in a folder on your machine, and you can version control that easily.
The code for workbook apps is stored inside workbooks. While there's no version control functionality in QueryStorm, it does let you export code from a workbook into a folder, as well as import code from a folder into a workbook project. There are context menu commands for this in the code explorer pane. This lets you decouple the code from the workbook.
Basically, for version controlling code in a workbook, you'd have to export the code into a folder and version control it there. Exporting into a folder will clear everything from the folder except hidden stuff like the ".git" folder so your git repository will be safe. Not a perfect solution, but it can be done.
ComponentSource is currently the only reseller: https://www.componentsource.com/product/querystorm-plugin
Thanks for the heads up!