Let me try and cover most limitations by saying this: a spreadsheet should basically be an interface to a Lisp interpreter. The ability to define new functions (within the spreadsheet itself) is the biggest thing, I guess. But if the spreadsheet is just an interface to Lisp, you get everything else, too.
Another problem is that you're stuck working with tables. Tables are great, but I want to be able to edit other data structures in a spreadsheet-like way.
Especially trees. Trees are everywhere. Mathematical functions, HTML, code in pretty much every programming language, XML documents (which include Word and Excel). All trees.
Joel Spolsky claims in his Trello post (http://www.joelonsoftware.com/items/2012/01/06.html) that Excel is about simple creation of tables, and great mass-appeal products are about the data structure they revolve around.
I think trees are underserved. I want to be able to write a tree, not 2 + 4 * 5 / 6, or <html><head><body></html>, or (((()()()))()())))(()()()())).
Plus you don't have to give up tables. Making a table out of a tree is easy (think HTML tables). Modeling a tree with a table is more clunky, in my opinion.
I think that a well-designed product along these lines could drag millions of "non-programmer" spreadsheet users all the way to Lisp.
I think that a well-designed product along these lines could drag millions of "non-programmer" spreadsheet users all the way to Lisp.
I love you! Please email me. Address in my HN profile.
The ability to define new functions (within the spreadsheet itself) is the biggest thing
Agreed. There are others, but if you have functions, especially functions as values, you can build most of them. But it isn't obvious how to integrate "native" spreadsheet functions into the spreadsheet as we know it. (Even Simon Peyton-Jones co-authored a paper on this, to little avail.)
Joel Spolsky claims in his Trello post that Excel is about simple creation of tables.
Right, thereby implying that Trello is what Excel really wants to be for most users. I bet against that. I don't think there's a simpler tabley core struggling to emerge from Excel, I think Excel is the core. The spreadsheet is the local optimum, and local alternatives will either fail to attract users away from Excel and/or get sucked into the black hole of becoming spreadsheets themselves. Why? Because spreadsheets let users play with data in a way that nothing else does. Excel isn't static tables, it's interactive computation.
Of course, when they eventually add formulas to Trello, Joel will write brilliantly about how everybody needs formulas. :) But can you iterate a quite-different product into a general-purpose spreadsheet? I don't believe so. That's Greenspun city.
I think trees are underserved [...] Plus you don't have to give up tables. Making a table out of a tree is easy
Here we may diverge. If the spreadsheet is a UI for a dynamic table, what does the UI for a dynamic tree look like? Seems to me you're likely to end up with something quite different-looking, which will make it hard to appeal to Excel users.
Making a table out of a tree is easy (think HTML tables)
Meaning the table as a root node, rows as children of it, and cells as children of rows? Again, though, the UI won't look like a simple Excel-style grid if it needs to render all trees instead of only "square" ones. The danger here is that if you make something too abstract, you lose the non-programmer spreadsheet users, the great bulk of the audience. Your tree idea lives or dies on whether there's a simple, general UI for it - where "simple" means "seems simple to Excel users". And also, I suppose, on whether there's a natural formula language for referencing data laid out in trees. Data references in formulas are critical to the way spreadsheets work, and they're the hard part (other than that, expression trees are easy to compute) - and the way spreadsheets do it relies on the grid layout.
Modeling a tree with a table is more clunky
It is clunky, yes. I'm not sure how to do it well. When people lay out hierarchical data in spreadsheets they tend to use indentation to indicate parent-child relationships. Significant whitespace I guess!
Another problem is that you're stuck working with tables. Tables are great, but I want to be able to edit other data structures in a spreadsheet-like way.
Especially trees. Trees are everywhere. Mathematical functions, HTML, code in pretty much every programming language, XML documents (which include Word and Excel). All trees.
Joel Spolsky claims in his Trello post (http://www.joelonsoftware.com/items/2012/01/06.html) that Excel is about simple creation of tables, and great mass-appeal products are about the data structure they revolve around.
I think trees are underserved. I want to be able to write a tree, not 2 + 4 * 5 / 6, or <html><head><body></html>, or (((()()()))()())))(()()()())).
Plus you don't have to give up tables. Making a table out of a tree is easy (think HTML tables). Modeling a tree with a table is more clunky, in my opinion.
I think that a well-designed product along these lines could drag millions of "non-programmer" spreadsheet users all the way to Lisp.