Slashdot Mirror
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.
Multiply 850*77.1 correctly?
while(1) attack(People.Sandy);
SQL databases have become much lighter and more efficient these days. Why should I use this store data over a lightweight SQL database?
We all know what to do, but we don't know how to get re-elected once we have done it
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?
Your hair look like poop, Bob! - Wanker.
Organising code on a spreadsheet... I guess it will resemble Befunge
and allowing spreadsheets to back-end websites
munge them?
hack them?
copulate with them?
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
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.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
A good portion of spreadsheets actually should be database tables of some kind. People end up manually grouping and other stuff that report-writers can do automatically. What is needed is a kind of "dynamic" RDBMS tool that has open-ended columns and column widths. A "spreadbase"? The Oracle clones are all too rigid.
As far as spreadsheets for programming, I've experimented a lot with data dictionaries to simplify column management and column sub-sets for regular ol' edit-and-report screens. So far it is tricky because one often wants to tweak something for a particular context and one-size-fits-all hits a wall. The trick is finding a good, clean way to "override" specifics from the table when needed or just make alternative entries of a given column and select them via set notation when needed; but I've yet to find a clean, simple convention. It ends up fairly messy such that regular copy-and-paste is unfortunately the cleaner solution much of the time. Maybe if the toolset and the language was geared toward nimble data dictionaries, these approaches would be smoother. Forcing a non-data-oriented language to act data-oriented is like trying to keep a toddler in line.
Table-ized A.I.
Wow... that screencast is perfect for me to sit facing the screen with my eyes closed, and anyone that walks past my cube will think i'm doing some spreadsheet wizardry....
nice. Now i'll go someway toward meeting the quota for those that sleep at work.
I never, ever want to see A1..A10 again.
Give me an item dispenser, the program should name things sensibly as they're created and all formulas should read as plain text like: profits = sales - expenses.
Please.
William
Sphinx of black quartz, judge my vow.
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.
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:
- Very few people use it, and
- 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.
The society for a thought-free internet welcomes you.
I've always felt that MS Access is a really shitty implementation of a really good idea. Yes, it was backed by an SQL database, but you can do spreadsheet stuff, too, and behind the scenes you could tie it all together and make it look nice. Another nice feature is that managers, with no programming experience and just a bit of SQL knowledge, can create and generate their own reports without having to bother a developer. Alas, the SQL engine has many fatal flaws, the scripting language is junk, and the GUI is just too quirky and weird. The report stuff is pretty nice, though.
Unfortunately nobody else has ever tried to do it right. The pieces are all out there, but they're not integrated.
I may be a diehard Red Sox fan, but I still cheer when a Yankee makes a good play.
It's been done: Pipedream by Mark Colton (also called View Professional) was a combined spreadsheet-WP-database app that ran on the BBC Micro, Archimedes and (even more weirdly) the Sinclair Z88 laptop computer. This Z88 review has a section describing Pipedream.
-- Ed Avis ed@membled.com
I am wondering if we have forgotten this cute little app... Thwe webpage says
2000-12-07, but I think I've played with it long before that. And yes, it had
database connectivity, could serve data over HTTP and, of course, the extension
(and half of implementation, I'd guess) language was Scheme.
http://siag.nu/siag/
Paul B.
Cells is a mature, stable extension to CLOS that allows you to create classes, the instances of which have slots whose values are determined by a formula. Think of the slots as cells in a spreadsheet (get it?), and you've got the right idea. You can use any arbitrary Common Lisp expression to specify the value of a cell. The Cells system takes care of tracking dependencies among cells, and propagating values.
Resolver seems to take this idea a step further. It looks like you can write nice reporting tools with this. There is no need to bash Resolver because you don't like Access or Excel.