Spreadsheets are one way of consuming 2D _data_, which most business data is. They also provide a very easy interface for thinking about basic transformations on this data: the data is very visible, and every transformation you make is therefore very visible as well. Really: it means folks don't have to worry about control flow.
I agree with other commenters as to the effects of 2D code. I've spent the past year talking to 100s of Excel power users, and it's pretty clear: at any scale, spreadsheets get incredibly hard to follow, audit, and maintain.
The best of both worlds, IMO, is a spreadsheet for data visibility, and a program for transformation visibility. I'm a bit biased though, because this is exactly what we're building at Mito [1].
If you want to see more of our thoughts on the topics above - check out this blog [2] exploring the relationships between REPL environments, spreadsheets, and noteboooks!
[1] https://trymito.io/hn [2] https://trymito.io/blog/repl
claiming that it's the code's 2D-ness that makes it beneficial
1. What's the pricing model. I'm guessing it's not free or open source, but I can't even confirm that from the website. This is enough to bounce me from a product like this.
2. Is there reference documentation somewhere? I've been bitten before by enterprise products that only have getting started documentation, and I'm not keen to be bitten again.
3. I can find documentation for importing data, but not exporting. I assume it's available, but I can't quickly confirm it, and that feature is absolutely critical for the use case I have in mind. This sort of goes back to the reference documentation point as well...
Here's the use case I have in mind. My Mom, who is somewhat capable of programming but not an expert (anymore), runs a online plant store. As part of running this she has a bunch of scripts that transform one spreadsheet into another, e.g. combining a supplier price list, a list of images, and a bunch of data cleaning, into a csv that can be uploaded to shopify to create a list of products. Or turning a list of orders from shopify, fetched via json, into a spreadsheet that can be sent to the supplier as a single order.
Tooling that made this process simpler, easier to debug, etc would be (or have been) great (especially for me, the professional software developer who gets pulled in to help whenever things get too complicated). I took a look at this product with an eye towards that.
To be honest I'm not much of a sales lead, apart from the fact that the business is tiny, the software definitely isn't being rewritten during the summer (busy season), and it's probably not being ported to a new framework at all (why would it be, what exists works). Still, I'm curious about what your software can do, and if it would have been appropriate.
Having used Excel way more than I expected last year, I agree with this. Transforming data one time to explore it on Excel is really easy and nice. On the other hand, trying to automate the steps that other people do manually is often not so nice and easy and I'd love to be able to use something else than VBA, something like pandas for exemple.
As an aside, I've been looking for a tool to handle spreadsheets with a few millions rows and that can be used by people without too much experience with programming. Do you think Mito would fit this use case?
What we get from spreadsheets that is quite nice, formatting-wise, is the cell data being of a rich type. A number of larger size doesn't take up more symbolic space, and therefore it remains fungible as a whole, rather than being round-tripped between number, string, number as is often the case.
When we use plaintext, suddenly a need for explicit binding of literals arises, and we become prone to "thinking" in terms of that binding layer and its apparatus, versus, say, something with a spatial analogy like a stack machine. They're Turing-equivalent, but one or the other may solve a problem more adeptly.
A 2D view of code layout could be useful in this sort of secondary radar way for learning a new codebase, refactoring, etc.
As a primary mechanism for writing code, outside specialized applications like graphics shader development, I'm not sure it makes sense.
2D layouts are simply too hard to follow once things start getting complex. You spend a lot of time reorganizing stuff. If you find writing clean code hard, making clean graphs is hard squared. As for spreadsheets, they are good for manipulating data, but for logic that is a little bit complex, they are terrible.
The author claim it is better for parallelism, but even for the most parallel application: chip design, most people use text-based "1D" programming languages (HDL) when things get serious.
Also, do you remember UML? It used to be super trendy in the 90s. Now, I almost never see it used. Sometimes you get a class diagram, usually generated from code.
2D layouts can be nice on a very high level. Connect the boxes. Digital audio workshops tend to work like that, but behind the boxes, this is regular code.
I see no benefit to a 2d layout except in a few special cases.
They don't need to live in R but it's a nice place to visit to understand the paradigm they're discovering.
