Coda, a “next-generation spreadsheet” – from rows and columns to custom apps | Hacker News Reader

Coda, a “next-generation spreadsheet” – from rows and columns to custom apps

theverge.com

262 pointswellokthen160 comments

>One of Mehrotra’s chief frustrations with the older generation of documents was what he calls “the game of Battleship” — the need to describe rows and columns in formulas using headings like “A1 to F7,” as in the old board game. In Coda documents, rows and columns are named objects, making formulas both easier to read and write.

Lotus Improv from 1991 had "names" instead of rowcolumn coordinates. Quantrix from 2003 also has named "items" instead of rowcolumn coordinates. Neither product had widespread adoption.

It seems plausible that cryptic rowcolumns would be a major paint point for most Excel users but maybe it isn't.

Quantrix found a niche in financial modeling so maybe that domain of users (~50k users) value features like that enough to not use Excel.

Google Sheets continued the tradition of cryptic rowcols and has more adoption than either of those alternative products. (Probably because it costs $0.)

[1] https://en.wikipedia.org/wiki/Lotus_Improv

[2] https://www.quantrix.com/QuantrixandExcelWhitePaper.pdf

Excel also has named rows/columns and cells - one of the bunch of useful tips I learned from Joel Spolsky's "You Suck at Excel" presentation - here's the part where he covers that: https://youtu.be/0nbkaYsR94c?t=25m54s

Excel also supports Multiplan-style RC syntax for cell addresses, if you like. I find the syntax a bit more clear, but ultimately too verbose to be useful.

R1C1 = Row 1, Column 1. R[1]C[1] = cell one row over and one row down.

One other point worth mentioning is that cell-relative references in Excel are more pervasive than they might appear. For example, you can specify a conditional format formula that highlights a cell if it has a different value than the cell immediately above. (Or a number of other more considerably complex scenarios.)

Range names work this way too... it's possible to define a range of the form "three cells to the right of the current cell".

Multiplan... now that's a name I haven't heard in a long time.

Excel has named columns with "tables".

Random tutorial off Google:

https://www.excel-university.com/indirectly-refer-to-table-c...

Excel 2007 solved the naming problem with tables. You can refer to cells in the same row, or an entire column or range of columns. https://support.office.com/en-gb/article/Using-structured-re...

Edit: and of course individual cells can be renamed since forever.

Data tables can also make things considerably faster. A colleague of mine once made a spreadsheet something like an order of magnitude faster by switching to data tables. (Maybe more speedup than that, even.)

Assuming all you ever care about is tabular data.

If you are building a business plan in Excel, or trying to explain how the financial accounts consolidates in a large organisation with multiple subsidiaries, tables are not particular useful.

That's the catch with Excel. One application, thousands of very different use cases.

So how do named columns help with non-tabular data?

That's my point, they don't. If your table is a complex calculation, not data, named columns don't help you.

Numbers (Apple) also names cells based on row/column headers.

Apple's Numbers spreadsheet has this feature today as well.

What I love about Apple's Numbers is the canvas approach. An idea that if Microsoft should steal if they were still developing Excel.

I like it quite a bit myself. But I don't make heavy use of spreadsheets.

what would that be ? googling for apple numbers canvas is not very fruitful https://www.google.fr/search?tbm=isch&q=Apple+Numbers+canvas...

This is a good example: https://images-na.ssl-images-amazon.com/images/G/01/software...

Basically a sheet is a blank canvas on which you can drop tables or charts or other things.

You can see on the left the list of the sheets, and within the list of the objects they contain.

It has all sorts of benefits over Excel's one grid approach:

- You can display two tables, one above the other, and the first can overflow without pushing the bottom table off-screen

- You can display two tables, one above the other, and the columns do not have to be aligned / have the same width (I am sure everyone using excel ran into this problem), same thing for row height for side by side tables.

- If these tables contain data, it allows to separate logically data on the same sheet instead of relying on empty columns as a convention. You can then filter the two tables independently but have both always visible on the same sheet

- Makes more sense for positioning charts vs tables

- Preserves the full flexibility of a generic excel grid, i.e. one object could be a table containing data, the other could be some complex calculation, etc. Excel has some ways to present data in a similar way but at this stage it is just summary data, not a generic spreadsheet

Anyone trying to unseat Excel is going to have the same problems as people trying to unseat Facebook: they already have lock-in of the vast majority of the userbase.

I use Google Sheets for most spreadsheet work now, but I was never heavily invested in Excel. Everyone I know who is a serious Excel user just isn't interested in anything else. Excel does everything they need it to do, and they have years worth of templates and formulas developed for all their needs.

Excel is also extremely robust. You can, for example, do VLOOKUP between tables that are ~10K columns by 100K rows. And it just does it. And pauses/restarts calculating, if you need to tweak something. But Calc? It just freezes, and eventually dies, and then must rebuild the file after restart. Which may end up being impossible. Indeed, Excel will do pivot tables that choke MySQL :) And it uses multiple processors.

I do a lot of work in calc but there is a definite problem with large files..and they aren't solved by adjusting thr included memory options.

Yeah. I've tried messing with those too. No luck. Calc seems to crap out at about 10 MB. Anything over 5 MB is prone to freezing. Especially if you use AutoFilter.

The first time I encountered the file-repair prompt, it was total déjà vu to the DOS era ;)

Yes Autofilter kills performance even moderate sized files.

That's a key point. If you want to get a share of the Excel user base, you're new offering needs to be Excel compatible.

I don't know what the intersection of 'most' and 'power' Excel users is, but as a very casual user I rarely need to explicitly type cell references because I can click to select which cell I'm referring to in the formula. Since Excel does multicolour highlighting it's easy to check that the right cell was selected. If I need an absolute reference (or whatever) I can go in afterwards and modify appropriately.

Named cells does significantly improve the readability of spreadsheets at a later date though!

I suspect path dependence (and price for quantrix) more than anything is what keeps Excel in charge.

I mean even beyond just switching costs: Excel is for instance the only format for getting data from http://www.earthchem.org/petdb/ or, to keep harping on geologists, people that keep implementing models in excel: which you then have to use because nobody trusts code you wrote yourself.

and it only gets worse with time.

Yet ironically, Excel introduces errors.

http://www.sciencemag.org/news/2016/08/one-five-genetics-pap...

I don't know if it's ironic in any useful sense, so much as fucking depressing.

though yes a calculator that refuses to let you enter numbers correctly is some 'Time Enough at Last' levels of irony.

It's not specific to Excel. Calc does it too. Turning off all that auto-correct bullshit is one of the first things that I do with a new install.

Lotus Improv was one of the best programs I've ever used, and I wish it would come back in a modern form. It was much more sophisticated than just having "names" instead of row/column coordinates. It had an easier to use and in some ways more powerful version of PivotTables. Man, I miss Improv.

Frankly that statement puts the whole company into poor light; if you are building an Excel competitor, you better know Excel pretty well. If your chief frustration is battleship coordinates then that does not exactly evoke the feeling Excel expertise, or that they have done sufficient market research. Or maybe they are not really targeting Excel as hard as the article posits?

> If your chief frustration is battleship coordinates

I read that more as a way to demean Excel by comparing it to a toy than any kind of exhaustive list of complaints...

Point being that if he actually knew Excel then he'd also know that Excel supports named columns just fine. With statement like that, he presents himself as ignorant of the basic features of their main competitor, which is not exactly great way to win the power-users of mentioned competitor.

I'd be inclined to attribute that to messaging more than understanding. I hear what you're saying, but a fully qualified statement that captures all of the details both loses a lot of impact and isn't the kind of thing that would appear in the Verge.

Exactly. It's the same problem as communication of science to the general public: if you make it 100% accurate, most people either won't understand or won't care. After enough customer interviews you start to get a sense of what gets people nodding their heads, and that's what makes it into these articles. Assuming that statements like this reflect a company's complete understanding of the problem just isn't fair.

I don't think it's a question of whether it supports it or not, it's that Coda does it by default and has built the rest of the tool around that feature.

I think the problem is that almost everyone uses excel for different things, and that lots of people feel like they know excel when they barely scratched the surface. But the reality is that 80% of excel users probably only need basic table formatting and basic formulas.

To some, excel is a data analysis tool. For those, all excel should have is big tables where every column should have a name and you would only ever do simple operations between them. To them, things like pivot functionalities, or connecting to database is critical. Data visualisation too.

To others, excel is a way to format a table, display a planning, a work flow.

To others it is a calculation scratch pad.

To others it is merely a UI, calling powerful custom XLL or calling server APIs that will do some complex pricing, book or retrieve trades from systems and whatever.

To others it is a full feature model builder, they will run some complex business plans, with all sorts of ratios and calculations that are unique to this use case and can't be generalised by an IT dept.

To others it is a custom app, with forms, lots of VBA code, etc.

For most people it is the "xml" (as in common standard format) for users to exchange data that they can open, inspect and reason without requiring a degree in computer science.

etc

So on one side there is nothing that annoys me more that someone pretending that all an Excel user ever needs is this particular feature and that he will replace Excel with that little website.

On the other side it is true that for parts of the Excel user base, all they will ever need is one particular feature and one could take a bite at Excel's market share.

The feature might be there, but if the design causes 99% of users to not use it or not be aware of it, it doesn’t matter.

It turns out that not having to name things is a feature. Users often avoid naming things and dislike being forced to do so.

The reason is what developers already know: naming things is hard! (Two hard problems, etc.)

Of course, developers also know how valuable good names are, so we like to take the time to pick good names. Users would rather just skip naming altogether and refer to things by letter/number or just by clicking on them.

Yes, clicking on "this thing right here!" is a powerful way for ordinary users to create references. It shouldn't be underestimated.

Programmers are so used to having to name things that we don't see the mental overhead of using names. A named cell is conceptually a pointer -- you can change what it points to (by giving the same name to some other cell instead), and if you delete the referent, it can point to nothing. That kind of invisible indirection is not easy for non-programmers.

An important thing about cell references that makes them almost but not quite entirely unlike pointers is that they can be relative, absolute, or mixed.

https://support.office.com/en-us/article/Switch-between-rela...

Aren’t named cells/columns a category of their own? They’re not relative nor absolute, but resolved by the name binding that exists at evaluation time.

>It turns out that not having to name things is a feature.

I think this is one of those great insightful points that's counterintuitive and yet has abundant real-world evidence we can't deny.

I'd guess that vast majority (99%) of programmers that program in languages requiring explicit variable names (Python, C, Java, Go, etc) will still use Excel without named cells nor named columns. Yes, they will label their adjacent cells with freeform text (e.g. "TOTAL PRICE:") but they won't use the Excel "named regions" feature to be referenced in formulas. How do we reconcile the inconsistent attitude we have about the benefits of names?!?

It turns out that yes, naming cells is a form of "code documentation" and helps avoid "spaghetti formulas" -- but it's also a friction. If programmers using Excel eschew cell names, it's a given regular users will too.

It also doesn't help that "names" in Excel is not a 1st class feature. It's a separate menu item and the name is a hidden "alias" for the cell.

With other products, the "name" of the cell is what you type into the box right there on the sheet. The UI for giving a cell a name is more immediate.

Range names come at a price. Try copying a sheet into another workbook that has conflicting names. Or copy-pasting your table in the same sheet to do something slightly different.

I use excel a lot and I found that the only convincing use case for range names is if you need to refer to ranges from VBA, then this is the only way for the code to find its way on a spreadsheet even if someone inserts some rows and columns. Otherwise range names create more problems than they solve.

>>Try copying a sheet into another workbook that has conflicting names.

This is really like copy pasting code from one namespace into other, with code in both spaces having same variable names.

You really need to think of a spreadsheet as a function. It must have single responsibility and must be called by another sheet to be used.

And now you're designing a system which has none of the benefits of Excel for end-users, again.

We are designing nothing, excel allows you to create variables with names assured unique in a namespace(A single spreadsheet). You could use it any way you like.

But if you are copying a formula that has things like variable names into a new sheet, you have to understand that pasting the formula with its variables pointing to nothing is like inducing a NullPointerException.

Yes, the point is, this is why people avoid naming things in Excel. Getting them to name things removes functionality.

In the following case:

     //B1 is renamed as first
     //B2 is renamed as second 
     _______________
      f(x)| C3 = first * second
     _______________
       A | B | C | D
      _______________
    1|___|_2_|___|__
    2|___|_3_|___|__
    3|___|___|___|__
    4|   |   |   |

     _______________
      f(x)| C3 = B1 * B2
     _______________
       A | B | C | D
      _______________
    1|___|_2_|___|__
    2|___|_3_|___|__
    3|___|___|___|__
    4|   |   |   |

It barely matters if you copy paste the first one or second one into a new sheet. C3 will be pointing to null. If anything its easy to trouble shoot former because you can chose any cell in the spreadsheet and call it 'first', chose another and call it 'second'- Compared to say to having fixed cells B1 for first and B2 for last.

I didn't know excel allowed you to assign names to cells. Nobody taught me so. Of course I'd find it useful if the UI for that feature was easy to reach.

In programming the UI to assign names is very intuitive and right there in your face. You place the name next to the thing you want to have named. Done.

In Excel it is both, very accessible and not obvious at the same time.

At the top left corner of the sheet, just to the left of the formula bar, there is a textbox that displays the cell Number (eg. A1). Simply click on that and enter a name for that cell.

But the fact that people routinely do create labels for cells, and have columns with headers is also a hint that the people are willing to name things.

So it does come down to a UI issue after all: the right UI for getting users to name things is one they want to use for labels/headers.

Those are great points.

From that perspective it's very telling that the editor's/document's/spreadsheet's/product's name was taken from a long-time editor for the web, Coda.

This is on top of the glaring issue that, if my formula says multiply "itemCount" by "itemPrice"... Where do I actually find those things? If I see A2 referenced, I know exactly where to find it.

that is exactly the reason why developers dont get the naming/not naming conundrum, A2 is a better name than itemCount and a better way to reference when dealing with hundreds if not thousands of variables, the advancement would be actually the ability to autoname vars and then allow users to rewrite them in case of inaccuracy, and also still allow for coordinate mapping bringing the best of both worlds

Does it really make sense for someone who doesn't understand the concept of 2D Cartesian coordinates to be using a spreadsheet at all?

"Battleship coordinates" are pretty darned far down the list of Things Wrong with Excel. Considering you still can't open multiple instances the way every other Windows application on the planet works...

On Windows 7, Excel 2013 I can open multiple instances. They still share the same undo stack though.

It can only open multiple instances if you launch them explicitly. If you click on multiple .xls(x) files, they will still open in the same window.

It's just insanely stupid and nonstandard.

>>It seems plausible that cryptic rowcolumns would be a major paint point for most Excel users but maybe it isn't.

Its not cryptic, its the most intuitive way of finding the position of a cell in a spreadsheet.

      ABCD
      ____
    1|abcd
    2|efgh
    3|ijkl
    4|mnop
    5|qrst
    6|uvwx
    7|yzAB

It becomes a whole lot easier to give the position of the letter 's', I just have to say C5. Instead of giving a name which the user has to hunt in a large spreadsheet. Its easier to look up things in a sequence, than look at an arbitrary name.

Besides you can always name a cell in Excel and use that in a formula.

> It becomes a whole lot easier to give the position of the letter 's', I just have to say C5.

Except that doesn't work correctly if you move the formula around, whereas R5C3 does (and makes relative addressing very explicit).

How is saying Row 'C' , Column '5' any different than saying Row '3', Column '5'. These are just ways of pointing to a cell with regards to its position from the cell at the top left column & top left row in the spreadsheet.

> How is saying Row 'C' , Column '5' any different than saying Row '3', Column '5'.

Well an obvious reason is R1C1 clearly spells out which is the row and which is the column and further makes it very clear when you're using absolute addressing (RYCX) or relative (R[±Y]C[±X]).

But that's not what I'm talking about in the previous comment. What I'm saying is that A1 is implicitly relative: open excel or google spreadsheet, type "=A1" in a cell, then copy/paste it to an other cell, it won't be "=A1" anymore it'll be offset by the difference between the source and destination cell and thus may have become e.g. "=C8". To fix that you have to "lock in" the dimensions by prefixing them with $ e.g. $A$1 does not move around at all, $A1 does not move in the column but may move in the row and A$1 does not move in the row but may move in the column. R1C1 does not have that issue, as a user you spell out explicitly whether you want absolute or relative addressing (in either dimension) and the software keeps thing exactly as specified.

I discussed this in this same thread. If your formulas are using values from from other cells, it makes sense to name them explicitly.

'TaxRate' makes more sense then 'Pick the value from the same row, three columns to the left'

> I discussed this in this same thread. If your formulas are using values from from other cells, it makes sense to name them explicitly.

Surely if you're not "using values from other cells" you don't need cell references at all, and then what do you care about A1 versus R1C1?

If you are building a non-trivial application you will end up using value generated in one cell, in another.

Its exactly like programming. A lot of state is stored in intermediate variables.

> Coda is a next-generation spreadsheet designed to make Excel a thing of the past

There are many projects aimed at making Excel "a thing of the past" but they focus on different needs:

o https://airtable.com - use tables for data organization (organize anything)

o https://fieldbook.com - spreadsheet as a database

o https://www.rowshare.com share data (share rows, not data)

o http://conceptoriented.com - data transformations and data wrangling (I am the author)

o Coda - integration with documents

It is interesting if one of these approaches will eventually dominate or we will have a zoo of spreadsheet-like applications.

There are many projects aimed at making Excel "a thing of the past" but they focus on different needs:

I think this is why Excel/Google Sheets still dominate and will continue to.

All of these products do one or a few things things that Excel or Google Sheet do, but perhaps they make it little easier for a novice. I think what people don't understand about Excel (and to a lesser extent Google Sheets) is that it's an IDE. A novice can build interesting things, a power user can build incredible things.

The only way to make Excel a thing of the past would be to make a blow-away awesome replacement that does everything excel does but better. There's plenty of blue ocean around Excel and I think each of the products you listed could do just fine.

I would love all of Excel's power available to me but delivered like Google Sheets. That would definitely kill Excel. So far neither Microsoft nor Google seem really committed to this. Google Sheets is nice but just grabs the low hanging spreadsheet fruit. Office 365 is anemic.

If I had the time and funding I'd love to make a true Excel killer that was a faithful recreation of ALL of Excel's capabilities but delivered in a modern way. I'd pay good money for this. I believe many would. Excel may be a dinosaur, but it's still the apex predator.

There's probably a case to be made for a simplified spreadsheet tool in a Basecamp/Trello mold.

I don't want simple. I want all the complexity and complex features. Everyone has a simple spreadsheet these days.

Then I have good news for you: you can use an existing spreadsheet app or a relational database!

I am genuinely curious to learn what do you mean by "delivered in a modern way"? Which parts of Excel are obsolete and could be modernized?

I can't speak for ryanmarsh, but I have a few thoughts.

* Excel really has two major ways of performing computations on data - formulas within the grid and actions upon the grid. Despite the utility of the formula based dataflow model, there are too many operations that have to be performed as one-shot operations via commands (or scripted via VBA). Having formula based approaches for sorting, dividing into bins, etc. would be very useful.

* It'd be nice if Excel cells could contain values other than scalars. (Arrays, tuples, lists, maps, matrices, complex numbers, etc.)

* VBA can be used to define custom functions, but there's a lot of marshalling overhead going to VBA and the programming model is slightly different. It'd be nice to fix both of those issues.

* There's no way to locally bind names within a cell formula, so often subexpressions have to be duplicated. (And I believe they're doubly evaluated too.)

Shameless plug: I'm a founder of Alphasheets, a company seeking to solve problems like these! I couldn't resist replying after seeing these comments.

We make a collaborative (Google Sheets style) spreadsheet with Python and R running in the sheet. You can define functions, plot using ggplot, embed numpy dataframes, matrices and all that good stuff. We don't let people use macros, all the code runs in cells because we think macros are too brittle. You can check out the website at http://alphasheets.com .

We're seeing that many enterprises (for example, in finance) that have Excel power users are moving to Python because of limitations like these, and are running into adoption issues because people like spreadsheets so much. That's generally where we come in and provide a bridge from the Excel world to Python through a more friendly frontend.

We're also seeing that Alphasheets can help a lot with shortening feedback cycles on more sophisticated data analyses- Excel is the most popular self-serve analytics tool out there, but doesn't cover cases where you need Python/R/fresh data.

That's awesome. Some of the details are different, but pretty much exactly what I was thinking when I wrote what I wrote.

This is very nice. Problem is, there are sooo many more features in Excel you'll have to copy to get me to move. If you ask "which ones" I'll say "all of them". I'm a power user. I build huge dashboards and analytical tools in Excel. The thing I hate most is that all my work goes into a file that I have to pray works on the other persons computer.

The product is great. But you guys will need to launch a fully feature rich desktop client, which can sync with the cloud.

Else its the same thing mentioned in the previous comments. You would build a web app with 5% the features of excel, and the moment somebody reaches use case that can't be solved with your tool, they will have to switch to excel. If they have switch every second time they use your product. They might as well do all their work in Excel to begin with.

You have to be feature compliant with excel and you can't do that on a web app alone.

It would be nice to:

* see a modern replacement for VBA, dare I say using JS

* be able to share a document that won't break when someone opens it on their computer (even if its using all the excel bells and whistles including external data sources and plugins). Google Sheets by contrast, is just a link.

* be able to use all the amazing features via the web and/or an app

> * see a modern replacement for VBA, dare I say using JS

Any .NET language is already modern enough and supported via Add-ins.

I just miss not having them fully integrated into Office, instead of requiring VS + VSTO.

Let's call Google Sheets "modern" because it can be used from an app or any web browser. I can share a Google Sheet much easier than an Excel file using all the bells and whistles.

The problem is, Excel has a ton of very powerful features. Many of which Google Sheets doesn't provide. Something like VBA would be nice. I'm aware you can write JS plugins for Google Sheets but the experience is no where near as good. Pivot tables in Excel still smoke Google Sheets.

Does GoogleSheets actually match Excel's feature list?

Not even close - I'd guess its about 20% of the features excel has.

That is what I thought.

Also https://zenkit.com/ (fairly similar to airtable)

Years ago there was DabbleDB - https://en.wikipedia.org/wiki/Dabble_DB And Simile Exhibit experimented with a dynamic UI for filtering / faceting tabular data - http://www.simile-widgets.org/exhibit/

The witheve.com stuff (and the underlying "differential dataflow") is also interesting as a model for derived data which updates itself. I'm keeping an eye on that project too.

As far as your site goes (I just took a brief glance), if you haven't seen it already, you might find some interesting ideas in the sieuferd project:

http://people.csail.mit.edu/ebakke/sieuferd/index.html

Oh, yea. DabbleDB was amazing! Eventually bought by Twitter. Here's a demo video.

https://www.youtube.com/watch?v=MCVj5RZOqwY

To throw my hat in the ring, I'm developing a prototype environment for data transformations I'm calling Flowsheets: https://www.youtube.com/watch?v=y1Ca5czOY7Q

Although my goal is to use it to understand how we can write software better.

Pretty awesome, bGlench! ;)

I wonder if a kind of hybrid programming would be possible which switches between this dataflow-like functionality for parts and more traditional ('large blocks of text'-based) techniques for other parts.

I was working on a simple framework a while ago where the highest-level organizational structure was a 'domain' and these domains would connect to one another via 'converters'. I think the dataflow format would work really well for defining and linking up domains, and small functions that do things like filtering would work well within converters—but then maybe within particular domains it's somewhat of a free-for-all again (i.e. you use traditional programming techniques). Just thought I'd share the idea on the off chance that it sparks something for ya—I'm not really doing anything with that project at the moment.

I'm also curious why you prefer the tabular format over something graph-based. Is it just that it's more straightforward for people to lay things out/organize?

Some neat ideas here! Also one of the most entertaining demo videos I've seen in a while :P

there is a typo in the first sentence of the welcome pop up

thanks!

I'm not currently a user but https://www.smartsheet.com/ had pretty advanced features that I liked. The UI was a bit old-fashioned but the tool is capable.

Thx!. First time I heard of rowshare and it is exactly what i am looking for. I wish excel or every excel like apps has this .

Sounds interesting, but are they not worried that the name is taken? https://en.wikipedia.org/wiki/Coda_(web_development_software...

Web editor and web spreadsheets aren't exactly the same field, but that seems close enough for a trademark collision.

Yeah - in the macOS community Coda is a fairly well known text editor for web development. The team at Panic should definitely stand their ground on this one...

Yep. I use Panic's Coda on Mac and iOS platforms.

I wonder how creative people can be with naming. Coda vs Coda. An editor vs an editor. Three years in stealth and this name... Well, if they change the name in the future, probably it will be... Excel! The new Excel.

This is an interesting comment, since they consider the power of names as a selling point.

https://news.ycombinator.com/item?id=15543362

And to add that Panic, who makes the software Coda you link to, makes really awesome stuff and has a very loyal following.

Direct link to Panic's Coda: https://panic.com/coda/

I really want to hate that project (too much hype and the UI looks like this just another crappy and locked in office suite). That said there is someone out there who is going to get it right. Excel has too major problems:

1. Legacy: newer versions will always need to support VB6 and activeX and all that garbage - that's quite a big drag.

2. Inability to track changes easily. (Just move a table one row down, and it becomes impossible to compare the 2 versions) which causes what people call "spreadsheet risk"

That makes Excel "somewhat" vulnerable to asymmetric marketing attacks. It is in fact surprising that this hasn't happened yet. I think one of the big reasons is that most SV people don't use much Excel (not like we financial guys do)

I'm just hoping that Mike Bostock and the 2 other guys as Observable HQ are going to nail it. I'd much rather have a totally hackable front end that does the DAG for me, than a cloud-based document-editing-with-formulae...

It has many more...

There is no good way to share data between spreadsheets (linked spreadsheets are a nightmare)

There is no good way to link a word or ppt document to a spreadsheet (an extremely common use case, think reports, client presentations). Linked tables are unstable (crash and unstable rendering) and you have to do all sort of hacks to ensure the links are not screwed up if you ever modify one while the other is closed.

Excel should move away from a single grid approach per sheet (Apple’s approach makes a lot of sense).

What is depressing is that outside of ensuring it runs on new platforms, Microsoft pretty much stopped development of new major features 10 years ago. If you look at the past Excel’s what’s new, these are mostly cosmetic/minor/maintenance changes.

You can make a shopping list in Excel, and you can also run a $100M+ company with it. It's probably the most important and powerful product Microsoft has made, right next to Windows itself. Anything taking on Excel would have to be able to do all that, while also offering so much more to overcome the friction of switching.

Otherwise it's just a niche product, which is still valid, but not really a next-gen spreadsheet. Coda seems like it would be great project management/CRM tool rather than a spreadsheet app.

See also:

https://airtable.com/

https://fieldbook.com/

https://quip.com/

and http://documize.com

I was confused when I saw this. I believe there is a bit of a name conflict with Coda[0] by Panic.

Nevertheless, this Coda looks quite interesting.

0: https://panic.com/coda/

Replying for no greater reason than to shill for Panic. Coda is an amazing tool.

Agreed. Great product.

Panic's Coda has been around since 2007 and is a well known name. Their latest release date June 2017 and is still very active.

It has over 100 reviews on the Apple store for their mobile version and their desktop version has hundreds of reviews on independent download websites and multiple blog posts by different developers.

Writing "Coda" on Google leads to Panic's software on the first page. So does "Coda Software", "Coda App", "Coda Download" and "Coda Review".

Coda.io has been around since 19th of this month. You can get to it (well, this article on The Verge) by writing "Coda Software" on Google, but it is on page 3.

Surely naming it Coda was a mistake. It leads to confusion and hurts their branding.

If something is going to be better than Excel because its "40 years ahead of it" it ought to be a native app and be more powerful than Excel. Excels value comes from its power features and ability to finesse with fine detail - simplicity isn't always the answer.

After reviewing this, and the coda site, I only have a vague idea of what it does, or can do.

it really makes me wonder who upvotes those links that have no products to show.

But can it open two files with the same name? If so, they have Excel beat.

For people who need this kind of thing, FileMaker can be an extremely effective solution. The article doesn’t really explain what is differentiating about Coda.

I was wondering how Coda differed from Quip, et al, but this article makes me pretty excited about it. As someone who used to spend all day in Excel and VBA, there's definitely room for a new "light coding" platform.

The only feature required to beat Google Sheets in my book: smooth scrolling.

The general idea of Coda, unifying document text and calcultion code is very attractive. Jupyter notebooks do something similar in a different Domain. Yet the result in Coda looks much more sleek and polished than Jupyters cells.

A smaller example of programs that go into the same direction would be Soulver (on OSX), NaSc (on Linux) or CalcNote (on Android). Theese three of course have a much smaller feature set and different goals than Coda.

The main culprit I see with Coda is the reliance on one closed source software product maintained by a commercial company with a closed source file format. I think Google (Reader) should have taught us something about relying on software that you don't even remotely control or understand.

Jupyters next iteration, JupyterLab, is giving users more flexibility in terms of screen estate layout, but it will look even more technical instead of more elegant and integrated. Maybe inspiration for further iterations can be drawn from Coda (and good old MathCAD) for a more integrated future version.

Until then staying with Emacs/Spacemacs and org-mode/org-babel gives you the flexibility for output in a lot of different high quality formats AND the guarantee that your carefully crafted documents will be accessible decades in the future.

I think the next successful spreadsheet might be compatible with xlsx and support a handful of fundamental clean data / database concepts. Things like enforcing keys, tabular structure, NAs instead of blank fields, types. These are simple enough you can teach them to average white collar workers and powerful enough that they would dramatically improve data quality.

What these guys got right is that Excel is actually an app development platform. The most successful one, ever. I wrote about it here: http://bi-review.blogspot.ca/2017/09/excel-is-application-pl...

Relevant http://witheve.com/

Neat for some use cases, however the fact that its only online will cause issues for some folks.

People process a lot of data in excel - sensitive, private data. Putting that data into the cloud with a startup (regardless of pedigree) will be a bit too much risk for some.

If you instead prefer your "next gen spreadsheets" simpler, open source and offline, you may like http://strlen.com/treesheets/ ;)

”We haven’t had an application creation tool like this since HyperCard. I think we’re going to see lots and lots of good experiments.”

”a collaborative document editor that combines a word processor and a spreadsheet”

I get the impression this is more like another attempt to do what Opendoc, the various ‘Works’ products of the ‘90s, OLE, Ashton-Tate’s Framework, etc. promised than a spreadsheet.

Question then is what would make this succeed at doing that where those products failed. That many people think they want something like it isn’t enough. Has the time for this kind of product come, is ‘collaborative’ the killer feature, or what?

“While Excel 5 was being designed, Lotus had shipped a “new paradigm” spreadsheet called Improv. According to the press releases, Improv was a whole new generation of spreadsheet, which was going to blow away everything that existed before it. […] Of course, Improv is now a footnote in history. […] Why? Because in Improv, it was almost impossible to just make lists. The Improv designers thought that people were using spreadsheets to create complicated multi-dimensional financial models. Turns out, if they asked people, they would discover that making lists was so much more common than multi-dimensional financial models, and in Improv, making lists was a downright chore, if not impossible.”

— Joel Spolsky

https://www.joelonsoftware.com/2000/05/09/the-process-of-des...

Archive.org link: https://web.archive.org/web/20170606181942/https://www.joelo...

Maybe improv was just ahead of it’s time. It wouldn’t be the first time we see a product fail only to have a similar one years later become a success. I bet there are more people using excel for complex stuff now, they might as well find a niche.

I think Improv was only solving one of the use-cases that you'd use a spreadsheet for - and thats why it was never widely adopted.

Yes. Kind of like saying that you could replace a general programming language with FoxPro because all you ever need to do is database related code. As a programmer, even if you only deal with database, you kind of like to have full flexibility to do anything you want and not be cornered in a specific use case and fight against the product if you want to do things slightly differently. Users think the same way, even if it means more opportunities to shoot oneself in the foot.

Disclosure: Spolsky worked on Excel for several years as a product manager, and is biased.

The other reason that Microsoft Office tools succeeded is that Microsoft was very good at all of the extra-technical stuff – business deals, marketing, software bundling, legal fights, etc., some of it quite underhanded/anticompetitive.

Lotus made Improv for NeXTSTEP originally, so there was a niche platform problem for the first 2 years, and after it had been ported to Windows Improv was competing against Lotus’s own previous spreadsheet program 1-2-3, creating consumer confusion and confusion within other parts of the Lotus organization.

But the main reason is probably just inertia. Once people have learned one tool that seems to work well enough for their needs, getting them to adopt something else (especially if it isn’t conceptually identical) is twice as hard.

He probably is biased - but it seems they were building "spreadsheet for advanced users" when most people who use a spreadsheet are not or will ever be advanced users.

Yet there is an enormous amount of important money-work being done by Excel users who are far more advanced than me, building what are essentially computer programs / databases.

So even if that market has fewer users then Excel itself, there an still be money to be made from people who could use a tool that is better behaved than a consumer spreadsheet but easier to use (for domain specialists) than a general programming environment.

This is the argument that (IMO, rightly) people make against the continued use of C for systems programming.

But C aficionados insist they understand its behaviors well enough to not get bitten...

I accept the analogy here between Excel and C, but I think the moral is the opposite.

Excel is very likely a good choice for a lot of people doing complicated stuff with it -- in spite of its problems. It's just that some of those people might also want a niche product that replaces it for some particular purpose. Not an entirely new, general purpose tool.

The problem with using a tool with say 5% of the features excel provides is you sooner or later run into some feature you need, but is absent in the niche tool. You can't exactly split your work between two tools now. So it just makes sense to use the tool with the super set of all the features, even if you don't use all those features all the time.

The right comparison for this would be using some thing like awk/sed compared to using Perl.

Apart from “home” use, Excel users usually lack functionality and tend to build an unmaintainable mess in their spreadsheets. Quarter of my ‘system integration’ work came from Excel users trying to automate and/or formalize what they created in there for years. Sadly, these types of businesses take hell of efforts to convert to good information systems; high failure rates are normal there. For me, Excel is a heroin of a business world. It drags you from reality and breaks you when you’re trying to get back into it.

>>Excel users usually lack functionality and tend to build an unmaintainable mess in their spreadsheets

Excel needs to be viewed as a programming tool. And a good programming tool is something that gives as much control to the user.

There are many Excel tutorials online and on Youtube that try to teach you how you can do MVC with Excel. That is separate presentation from data, and its control.

There aren’t enough trained programmers in the world to do in code what all Excel users get done with spreadsheets. Let alone programmers who understand the business of the company they work for.

It's the dream Microsoft Access should've been, but for whatever reason never caught on.

Microsoft tried it a few times, the latest attempt was LightSwitch, recently killed in favor of PowerApps.

https://blogs.msdn.microsoft.com/jasonz/2010/08/03/introduci...

https://powerapps.microsoft.com/en-us/

The thing is, with Excel the programming is gradual, you first just add some formulas, followed by conditional formatting, small macros, until eventually jumping into full VBA.

Alternatives, including Access, require good programming knowledge from day one.

But I still fundamentally agree with this approach. Perhaps not all users, but most users should be given a path toward more programming based approach to modelling.

I think lighswitch was stillborn when it wasn't distributed as part of office (irrespective of its merits, haven't tried it myself). Asking IT departments to deploy it was bound to fail. It needs to be available at the fingertips of excel users, like VBA is, always there, running with Excel, and you know it is available to everyone else so anything you do will run without having to install anything on their machine.

Powerapps look amazing to be honest. I actually would like to use that and the BI integration, but unfortunately I don't have enough reason to spend money on it. The small organising that I do need ends up in Airtable instead, but that's not even close. (I miss proper graphing features)

Spreadsheets exist because it would take programmers weeks to produce, what it would take a afternoon to do it in excel.

Plus most of the time these are one time throwaway efforts done to quickly arrive at results and make decisions.

It will all begin to make sense when we think of Spreadsheet work as programming and not something separate from it.

Oh god, this 'is biased' trope again. It's tiring. You can just say the first clause of that sentence and the meaning is the same.

I used to work in support for Lotus in the UK. A few people used Improv, but if IIRC once you got beyond a few dimensions the file sizes became huge.

The other alleged reason for Office beating our SmartSuite is the way new Windows or MS Dos releases always seemed to accidentally break Ami Pro or 1-2-3.

Demo of Improv on NeXT:

http://www.youtube.com/watch?v=TbsfvdZXE7s

Seems a lot like PivotTables crossed with a normal spreadsheet.

That's actually pretty cool!

Pivot Tables were invented by Lotus: https://en.wikipedia.org/wiki/Pito_Salas

Thanks. It’s interesting but even that solves a very specific use of Excel. It will become painful if you need to cross reference different periods, etc. I sort of built a similar calculation engine for work that works in a similar way, but it is a solution taylored to a very specific problem. Finance depart who would be the primary user for that would still need Excel on the side.

This is spot on.

The biggest reason why lists matter so much is because. Most data structure use cases in everyday life are lists, or lists of lists(Tables). Of course you have graphs and trees. But for all practical purposes, most problems there are, are either lists or tables. Excel will benefit, if they add optional tree and graph interfaces. Like you get an option to build a graph of how your business things are connected and help you figure the shortest steps to a solution etc.

And yes if you want to build a Microsoft Excel killer. Please build a thick client desktop application which is as feature rich as a Excel and give it away for free. Charge for the cloud usage. Anything less isn't going to cut it.

Excel is just way ahead of anything that is out there. The only competing product I've seen is Libreoffice Calc. But even that has a long way to go.

Also, you live in a 3D world, hence any non-cognitively overloading "work surface" has to be -1 dim, so 2D, hence List or ListOfLists (spreadsheet). Anything else will require brainpower you could be using for something else instead! (like solving the actual problem, not masturbating with the tools...)

Other alternatives are Trees, which are also "lists of lists" but without the size constraints (Graphs "look 2D" but easily grow multi-dimensional information-wise). But trees have a big problem: they easily grow bigger than the screen, so you expand/collapse them, so you always end up with hidden information that you can overlook - hence they are really bad for sloppy people (I know it from first hand experience... if I'm not careful I can really forget that whole sections or Wrkflowy trees or Org-mode documents I work with even exits!)

Now combining list & lists-of-lists & trees & formatted text could work, if they manage to not informationally overload the user.

But I'm 99% sure that any tool more complex than matrixes and trees as information shape will not take on wide scale, until we manage to couple it with some superhuman-Clippy AI-assistant that almost reads your mind. We're stupid monkeys and it's only so much our brains can handle...

Slightly off-topic, but speaking of lists...

http://www.spiegel.de/international/zeitgeist/spiegel-interv...

I'm going to stick with Excel for the row/column grouping feature. This seemingly minor feature enables multiple level of abstractions so different audiences can understand the spreadsheet in different views. As much as I want to move my team to Google Sheet or any other major competitors for easy collaboration, I simply can't.

Seems like an extra layer of cognitive complexity. Docs and Excel sheets are popular because they are simple but not simpler.

Would be interesting if cells of groups of cells in a spreadsheet could show a subset of the UI of another graphical program on the system. If it could allow user interaction with that graphical program then even better. That could allow users to build a dashboard of their running graphical software. Has this been tried before?

> Has this been tried before?

Yes, on Windows this technology is called OLE (Object Linking and Embedding). It allows embedding (parts) of other applications' documents in a document. Nowadays only a few programs besides the MS Office suite provide OLE capability.

For example, you can embed a complete Word document inside an Excel cell by clicking: Insert -> Object -> Microsoft Word Document. By double clicking this object, the Word UI opens up inside Excel.

I've begun to use the beta and see a lot of value.

One point of concern (and PSA): After creating a document, my browser blocked a CoinHive miner. As far as I know, there isn't a "best practice" pattern for passively mining, but personally, I like to opt-in to this sort of thing.

quick question for the Coda folks - How is it different from quip.com?

I don't think eye candy is killer app.

Distributedly consistent spreadsheets maybe? Make inner mechanics of a complex sheet easier to tackle? Add persistence and database capabilities that blend in?

i suspect more fluff than substance since this has been in the media all week with tons of fluffy articles about how much awesome it is. please prove me wrong

It's about time someone re-invented FileMaker Pro.

I love AirTable, which operates on a similar concept.

Coda is a text editor.

What's wrong with pure CSV, again?

CSV is hell. Some idiot somewhere decided that Comma Separated Values in certain locales should be based on semicolons (who would have thought files would be shared across country borders!?), so when we open CSV files that are actually comma separated all the information is in the first cell (until a semicolon appears).

To get comma separated CSVs to show properly in Excel we have to mess around with OS language settings. CSV as a format should have died years ago, it's a shame so many apps/services only export CSV files. Many developers (mainly US/UK based) are probably not aware of how much of a headache they inflict on people in other countries by using CSV files.

Actually you can change the extension from .csv (that Excel believes it can recognize) to something else and open it, the "import wizard" will let you choose the "separating character" and other settings that are very useful when importing Comma (or other character) separated values (such as forcing the "data type" by column). A good idea, however is to use TSV (TAB separated values) that can be usually copy pasted directly, it still remains in many cases the "feature" that Excel has to auto-identify data types, creating a mess with a number of pieces of data (such as a columen with Hex values, half of which will be "text" and the other half "numbers").

Trademark claim incoming from Panic, Inc.

Reply on news.ycombinator.com