The big data successor of the spreadsheet

I think the problem now is not a better excel but a better access; spreadsheets are pretty good at what they do but biz people use them when they should use a database because they find databases less intuitive.

Soulver is the best evolution of a calculator I've ever seen, think of it like a dynamic paper tape of calculations you can work with and alter and it keeps the results updated.

&quot;&quot;&quot;The interfaces require the end-user to know about the concept of a table, rows and columns, the concept of logical expressions, as well as aggregation, even though none of those are directly visible nor have a ‘real life’ analog.&quot;&quot;&quot;<p>This sentence expresses the problem I see with designers.<p>Instead of making that disappear into magic why not focus on actually purposely and clearly educating people about these CORE concepts?<p>edit: Think of how you would do this if you were Khan academy...

<a href="http://en.wikipedia.org/wiki/Powerpivot" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Powerpivot</a>

I work in a big, dumb enterprise with too many spreadsheets and Access databases.<p>What made me move away from Excel spreadsheets:<p>1) As in the infamous case, its too easy to miss extending a range when you add new data[1] 2) There&#x27;s no good way to manage concurrent access 3) Doing aggregates of aggregates is really hard<p>What made me then move away from Access databases:<p>1) Excel and Access attempt to guess the &quot;type&quot; of cell contents automatically, and this creates issues (Is 060E2 a product, or a scientific number? Of course, its 6000. Is 3&#x2F;6&#x2F;2015 a US date? Access will figure it out without you.) 2) There&#x27;s <i>still</i> no good way to manage concurrent access 3) Storage limits still aren&#x27;t that great if you want to deal with more than a few GB of data<p>For me the ideal spreadsheet would solve all these problems :) I moved to Postgres, instead.<p>[1]<a href="http://www.bloomberg.com/bw/articles/2013-04-18/economists-spreadsheet-error-upends-the-debt-debate" rel="nofollow">http:&#x2F;&#x2F;www.bloomberg.com&#x2F;bw&#x2F;articles&#x2F;2013-04-18&#x2F;economists-s...</a>

At my workplace we use SAS Enterprise Guide for some of this stuff. I like it because it has a drag and drop GUI that non technical users can utilise to extract data (It executes SQL queries in background) and do simple operations (like aggregations, statistics, graphs, merging, filtering etc) At the same time it has a decent programming language underpinning it and pretty advance statistical capabilities.<p>On the down side it still suffers from some of the problems the article references. Some non programmers, even quite technical people simple don&#x27;t grasp concept of querying and joins.<p>It is also horrendously easy for the auto generated SQL to be horribly inefficient the default appearance of the plots and other graphical output looks ugly etc, which leads to people doing things like extracting subsets of data from SAS and then pasting it into excel to manipulate it. Which is kind of self defeating.

The &quot;pipeline of blocks&quot; idea goes back a long way (Visual Smalltalk anyone?), I&#x27;m excited to see it applied in this way.

Datameer - big data spreadsheets<p>Scratch - best thought out block language