Jon Udell on the Nerd's Spreadsheet

rcs1000 writes "Jon Udell has a interesting article on a new type of spreadsheet: one targeted specifically at techies. The skinny is that any spreadsheet is actually a computer program, only in Resolver One, the product profiled in Udell's piece, this is explicit rather than implicit. And the code is IronPython rather than VBA. There are some other cool things it does — allowing cells to contain objects, and allowing spreadsheets to back-end websites." Udell's screencast gives a good demo, though the presenters are a bit hard to hear due to the phone connection. Resolver's own screencast is an alternative.

Comments

Why should I use this rather than SQL?

[quanticle]

SQL databases have become much lighter and more efficient these days. Why should I use this store data over a lightweight SQL database?

Re:Why should I use this rather than SQL?

[garcia]

Why use a database or spreadsheet? Why not something like the R Project?

Because you have to learn yet another cryptic set of functions to do what is easily accomplished in Excel (or any other spreadsheet)? Most people couldn't give a fuck less about using any package to its full potential and most people utilize Excel as a database rather than a spreadsheet (almost everyone in my wife's company for example).

A spreadsheet will do just fine for the majority of people and the rest would probably use something like Crystal Reports to do anything more advanced. Why? Because there is professional documentation and training available for those packages and R Project requires posts to mailing lists or forums to get answers outside of your own self research on the web. From what I can see in my own personal experience, people working in the real world don't want to spend the time searching around the Internet through mailing list posts and forums for their answers. They want to plunk down $350 and sit through a 6 hour seminar offering them 1 CEU.

YMMV.

Re:Why should I use this rather than SQL?

[ThrobbingGristle]

The question was almost certainly a response to the "Nerd's Spreadhsheet" bit.

See, the hyper spreadsheet is for nerds, just like R would be.

Did you consider his response in the context of the slashdot article/submission? Or do you simply have a grudge against people
who use software without "professional documentation and training"?

Re:Logical conclusion

[Anonymous Coward]

Life is a grid with a logic tree, dude.

Solution looking for a Problem

[OverlordQ]

In a Resolver spreadsheet, these objects are visually persistent. I haven't yet got my hands on Resolver, but here's an example of what I think that will mean. Suppose that I have a data set I want to transform, against which I'm testing five different versions of a transformation function. I'd put the data in cell A1, the functions in cells B1..B5, and the results in C1..C5. Now I'll see everything at a glance.

That . . . sounds just like a normal spreadsheet to me.
Solution looking for a problem?

The old saying is true.

[LWATCDR]

Everything looks like a nail when all you have is a hammer.
Spreadsheets are so useful today that they can do many tasks that are better done with other tools... If you know the other tools.

Re:Logical conclusion

[ResolverSystems]

This is exactly the issue Resolver is trying to solve. Spreadsheets - love them or hate them - are ubiquitous. One of the design intents of Resolver is really think through the architectural considerations for spreadsheet usecases. Traditional spreadsheets were designed for single-users, manipulating data in a file. Today spreadsheets are used for much, much more than that, however, the underlying architecture has not caught up. Resolver is changing this by applying a generic programming architecture to the spreadsheet metaphor. Python is an excellent environment for writing analytic software: simply look at the number of libraries and packages the scientific and finance communities have developed in Python.

Resolver is almost as much an integration tool as a spreadsheet tool: the architecture recognizes that various systems, such as databases, computing arrays, etc, may be the best places to store and analyze data. The goal of Resolver, then, is to give the developer or analyst a very powerful, programmable spreasheet metaphor for building applications and analytics.

VBA already does this...

[gillbates]

And does it poorly. And insecurely.

You can already access spreadsheet content from Visual Basic, and include VB script in spreadsheets. The same scripting ability which allows the "wow" features in spreadsheets also creates the potential for abuse - remember macro viruses? Suddenly, documents which formerly contained only data now contained executable code, and it gave rise to a security nightmare.

Yes, today, with VBA, you can do what the article mentions. In fact, it's been possible for years. Problem is that:

1. Very few people use it, and
2. Those who do use it tend to use it poorly.

Yes, you can back end a website with your spreadsheet. But why would you? A spreadsheet is a horrible way to manage data; there's no referential integrity checks, no versioning, no security, and doesn't scale well. Furthermore, your crucial data is tied to a particular application, rather than a database.

Just like VBA, it's a nice nerd's toy, but the wise system programmer recognizes that it has limitations.