Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Jon Udell on the Nerd's Spreadsheet

kdawson posted more than 5 years ago | from the easy-way-to-generate-code dept.

Software 168

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.

cancel ×

168 comments

Sorry! There are no comments related to the filter you selected.

Can it... (5, Funny)

O('_')O_Bush (1162487) | more than 5 years ago | (#20782707)

Multiply 850*77.1 correctly?

Re:Can it... (0)

Anonymous Coward | more than 5 years ago | (#20783101)

I would say yes ... but then I noticed that it's written in .NET ... so no!

Re:Can it... (3, Funny)

Daimanta (1140543) | more than 5 years ago | (#20783499)

And if you can, how do you maintain compatibility with Office Excel calculations?

Re:Can it... (1)

RobBebop (947356) | more than 5 years ago | (#20784653)

Yeah... the answer is 100,000. Right?

Re:Can it... (1)

The Assistant (1162547) | more than 5 years ago | (#20785517)

You forgot to convert from binary to decimal!

The answer is actually 32 , not to be confused with 42 (see Douglas Adams)

Logical conclusion (1)

MeditationSensation (1121241) | more than 5 years ago | (#20782749)

Oh jeez, this reminds me of the last company I worked at, where they tried to do *everything* in spreadsheets, even documents that would have been much better in word processors or databases.

Re:Logical conclusion (1, Insightful)

Anonymous Coward | more than 5 years ago | (#20782779)

Life is a grid with a logic tree, dude.

Re:Logical conclusion (4, Funny)

Teun (17872) | more than 5 years ago | (#20782903)

Life is a grid with a logic tree, dude.
It's called Tetris.

The old saying is true. (3, Insightful)

LWATCDR (28044) | more than 5 years ago | (#20782911)

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.

Storing, analysing and presenting Data (1)

voidspace (875081) | more than 5 years ago | (#20783215)

"even documents that would have been much better in word processors or databases." Well, that's true - but once your data is in a database you still need to analyse it and present it. Spreadsheets are used for three things: storing, analysing and presenting data. Most complex spreadsheets are actually *applications* for analysing and reporting on data. The things you get with databases are: a single authoratitive data source, transactions and queries. Most people producing reports don't want to do their analysis by writing SQL queries though! Part of the idea of Resolver is that it is really an application platform, with a familiar interface. Your data can be stored in a database (this is a good thing) and tables (worksheets) can be populated from database queries. You can then analyse (with real code if it is warranted) and present that data. You can also add user interface elements to push stuff back to the database if you want. It is massively cheaper than writing a custom application and a darn sight easier than doing the same thing with Excel.

Re:Logical conclusion (2, Insightful)

ResolverSystems (1163669) | more than 5 years ago | (#20783717)

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.

Re:Logical conclusion (1)

nategoose (1004564) | more than 5 years ago | (#20783733)

I worked at one of those too. Excel for everything. Annoyed the crap out of me.

Re:Logical conclusion - Absolutely amazing!!! (1)

corifornia2 (1158503) | more than 5 years ago | (#20784147)

This is absolutely an amazing product. It can do store objects and back a website!!! It can do all the same things as my well supported database product!!!

Re:Logical conclusion (2, Informative)

Ed Avis (5917) | more than 5 years ago | (#20785919)

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 [johnallen.com] has a section describing Pipedream.

Why should I use this rather than SQL? (3, Insightful)

quanticle (843097) | more than 5 years ago | (#20782761)

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? (3, Informative)

PJ1216 (1063738) | more than 5 years ago | (#20782821)

i don't think its a matter of storing data (or at least large amounts). thats never what spreadsheets were for. they were based more around displaying data and processing data. yes, they can be used for large amounts, but they never really were meant as storage in the same way a database was. they're just saying these spreadsheets could start serving some of the same purposes.

Re:Why should I use this rather than SQL? (0)

Anonymous Coward | more than 5 years ago | (#20782905)

A spreadsheet for techies....sounds like a database to me

Maybe someone should tell them that these have already been invvented

Re:Why should I use this rather than SQL? (2, Interesting)

Hatta (162192) | more than 5 years ago | (#20782937)

Why use a database or spreadsheet? Why not something like the R Project [r-project.org] ?

Re:Why should I use this rather than SQL? (3, Insightful)

garcia (6573) | more than 5 years ago | (#20783229)

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? (2, Insightful)

ThrobbingGristle (62723) | more than 5 years ago | (#20783497)

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:Why should I use this rather than SQL? (0)

Anonymous Coward | more than 5 years ago | (#20785405)

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"?


I considered it and thought about it some more and decided he was just trolling for mod points because he mentioned, what for most people, would be considered an obscure piece of stats software.

I don't give a shit how people learn about the software they're using. I was talking from the prospective of those that are actually in the real workforce, not the imaginary ones that everyone around here seems to be involved in. When you don't work with geeks (the vast majority of people don't) you don't run into shit like that.

Re:Why should I use this rather than SQL? (1)

TheCRAIGGERS (909877) | more than 5 years ago | (#20784655)

As somebody that has to work with useless vendors to get answers to my questions, I would jump at the chance to search through some forums to answer my own questions.

Re:Why should I use this rather than SQL? (0, Offtopic)

kalirion (728907) | more than 5 years ago | (#20783553)

Gotta respond to a part of your sig:

Patriotism is akin to racism.

This isn't true. Nationalism is akin to racism. There is nothing wrong with loving your country as long as you don't start believing that its citizens are somehow superior to everyone else.

Re:Why should I use this rather than SQL? (0, Offtopic)

Per Abrahamsen (1397) | more than 5 years ago | (#20784525)

> Nationalism is akin to racism.

That is not true. Patriotism akin to racism. There is nothing wrong with loving your country as long as you don't start believing that its citizens are somehow superior to everyone else. ...

Really, it is like geek vs. nerd. Some people try to assign all the good attributes to one of the words, and all the bad attributes to the other one. But it doesn't work, and not just because people disagree about which word should be the good one. The real reason is that the good and the bad attributes are connected in the real world.

Re:Why should I use this rather than SQL? (0, Offtopic)

nuzak (959558) | more than 5 years ago | (#20784873)

There is no requirement that you must love your own country in exclusion to all others. Anyone who decries the erosion of foundational rights, for example, is expressing patriotism.

In the end it's all about labels; Patriotism is whatever people want it to be, I guess.

Re:Why should I use this rather than SQL? (1)

DragonWriter (970822) | more than 5 years ago | (#20782975)

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


One of the selling points is using it to interact with SQL databases that are used to store data. From the resolver one homepage [resolversystems.com] :

Entire database tables, or the results of arbitrary SQL queries, can be imported directly into Resolver documents as new worksheets, which can immediately be used in calculations. If necessary, Resolver can update the worksheet in real time as the underlying dataset changes. Because there is no need for the user to write code themselves, this allows for sophisticated data analysis without assistance from IT.

Re:Why should I use this rather than SQL? (2, Funny)

Yetihehe (971185) | more than 5 years ago | (#20783147)

Because there is no need for the user to write code themselves, this allows for sophisticated data analysis without assistance from IT
Do you know what that means? Us techies will no longer be needed and we'll be disposed. Just like techie::destroy(); !

Re:Why should I use this rather than SQL? (1)

Waffle Iron (339739) | more than 5 years ago | (#20783797)

Why should I use this store data over a lightweight SQL database?

Maybe because SQL is a horribly awkward and cumbersome language for doing the arithmetic-oriented things that spreadsheets are typically used for.

Re:Why should I use this rather than SQL? (1)

ResolverSystems (1163669) | more than 5 years ago | (#20783855)

As pointed out, and many, many of us have experienced, while data does belong in database, an enormous amount of analysis takes place in Excel, or at least is published in Excel. The database support in Resolver is designed to allow the spreadsheet to be more closely tied to the database: the spreadsheet can display database data in realtime; e.g. when transactions occur in the database, the spreadsheet updates automatically. Resolver cannot control if users wish to use spreadsheets in places where databases may be more appropriate, but can provide tools to make it easier to use the appropriate technology in the appropriate place.

Solution looking for a Problem (2, Insightful)

OverlordQ (264228) | more than 5 years ago | (#20782781)

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?

Re:Solution looking for a Problem (1)

networkBoy (774728) | more than 5 years ago | (#20782877)

but storing a formula as an anon function is not normal for a spreadsheet, and honestly I think that may be a bit brilliant.
-nB

Re:Solution looking for a Problem (1)

C3c6e6 (766943) | more than 5 years ago | (#20782885)

Can you do that in a spreadsheet? Sorry if I'm ignorant, but I don't think you can put functions in cells and use these to manipulate data in other cells. To me, this idea sounds rather cool. A pity it isn't Open Source, but hey, maybe innovation still exists in the closed source world! :-)

Re:Solution looking for a Problem (1)

DragonWriter (970822) | more than 5 years ago | (#20783249)

Sorry if I'm ignorant, but I don't think you can put functions in cells and use these to manipulate data in other cells.


Lat I checked, you expressly could not in Excel with VBA custom worksheet functions. Even if you could, I'd certainly rather do it in Python than VBA, though.

Re:Solution looking for a Problem (1)

Miltazar (1100457) | more than 5 years ago | (#20783225)

Thats what I thought at first. However, I believe they mean you put a reference to a program in your code into the spreadsheet cell. That way you can do unit testing much easier then normally. Thats what I got out of it anyway. If that isn't what it does, then I agree with you.

Re:Solution looking for a Problem (1)

voidspace (875081) | more than 5 years ago | (#20784189)

Making spreadsheets unit testable is certainly one of the aims of Resolver.

Re:Solution looking for a Problem (1)

tepples (727027) | more than 5 years ago | (#20783935)

That . . . sounds just like a normal spreadsheet to me.
But the formulas can be written as Python expressions, calling user-defined Python functions. Can your ordinary spreadsheet do that on multiple operating systems?

Re:Solution looking for a Problem (1)

ResolverSystems (1163669) | more than 5 years ago | (#20783967)

This is not something we ever intended to promote, it is simply the bi-product of creating a powerful spreadsheet in Python, which happens to by a highly-dynamic, object-oriented language. We can, however, see interesting usecases for this, for example cellular analysis in bio-tech applications, in which complex molecular structures can be represented as an object in a cell, and a visualization routine can then be applied.

What's the difference? (0)

Anonymous Coward | more than 5 years ago | (#20782817)

Aside from having a console window for custom formulae and a debug output window, it is not that much different from a typical spreadsheet program. This can easily be built on top of existing office suites, if they haven't include them already.

2D programming? (3, Informative)

16384 (21672) | more than 5 years ago | (#20782827)

Organising code on a spreadsheet... I guess it will resemble Befunge [wikipedia.org]

Re:2D programming? (1)

$RANDOMLUSER (804576) | more than 5 years ago | (#20782921)

I had never heard of Befunge before, but I can tell you that you just gave an ex-Forth programmer a full-body shiver.

Allowing spreadsheets to what? (4, Funny)

winkydink (650484) | more than 5 years ago | (#20782883)

and allowing spreadsheets to back-end websites

munge them?
hack them?
copulate with them?

Re:Allowing spreadsheets to what? (2, Funny)

Anonymous Coward | more than 5 years ago | (#20783119)

No, back end. See Jack Thompsons latest court files for details.

Misuse of spreadsheets (4, Interesting)

Tablizer (95088) | more than 5 years ago | (#20782925)

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.
       

Re:Misuse of spreadsheets (4, Informative)

voidspace (875081) | more than 5 years ago | (#20783013)

"A good portion of spreadsheets actually should be database tables of some kind." Databses are good for storing data and spreadsheets are great for analysing and presenting data. Resolver works very well with databases and so makes it easier to keep your data there - and still have a powerful analysis / presentation tool.

Re:Misuse of spreadsheets (2, Informative)

DragonWriter (970822) | more than 5 years ago | (#20783115)

A good portion of spreadsheets actually should be database tables of some kind.


A good portion of spreadsheets are actually backed by 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.


While I think you are selling Oracle and its object-relational kin short if you think they can't handle what you seem to be describing, a more simply "flexible" approach is that taken by, e.g., SQLite where types are advisory rather than rigid. But in either case the DBMS is just the back-end storage engine, you still need a front-end piece that the business user can interact with in a friendly, visual way or program if necessary, that's where something spreadsheet-like comes in. Resolver one seems, at the outline level, to be a good way of approaching that.

Re:Misuse of spreadsheets (1)

Tablizer (95088) | more than 5 years ago | (#20783505)

more simply "flexible" approach is that taken by, e.g., SQLite where types are advisory rather than rigid.

That is true, but the user cannot add columns quickly. I'm thinking of having a reserved row for the column name. If you don't put a name there, then it is automatically named the spreadsheet column letter, or the like (and column letters can perhaps still be aliases even if you do have an explicit name).

But in either case the DBMS is just the back-end storage engine, you still need a front-end piece that the business user can interact with in a friendly, visual way or program if necessary, that's where something spreadsheet-like comes in.

Well, but spreadsheets have a grid feel instead of a table feel and follow grid rules instead of table rules. I suppose I'd have to build a demo to explain what I have in mind. I've just found the spreasheet metaphore lacking outside of what spreadsheets were originally designed for. They can do a table-like job if you tweak enough, but tweaking is tweaking.

Here's an explanation attempt: The difference in philosophy is sort of like the difference between positional arrays and associative arrays. Spreadsheets are more like the first and tables more like the second. Each has their place, but to use one when the other would be better gives you the feel that you're using the wrong tool. The ideal tool would allow one to pick positional row-wise or column-wise and the other "axis" associative as needed and visa versa. Generally a "young" spreadsheet starts out as positional, but you switch to associative as it grows up and needs more formality and tools (like group-based summing, views, and auto look-ups/joins).
       

Re:Misuse of spreadsheets (1)

DragonWriter (970822) | more than 5 years ago | (#20784327)

That is true, but the user cannot add columns quickly. I'm thinking of having a reserved row for the column name. If you don't put a name there, then it is automatically named the spreadsheet column letter, or the like (and column letters can perhaps still be aliases even if you do have an explicit name).


That's not really a feature of the DBMS, but of the UI, though. Given the generality of the programmability that resolver one appears to offer, it seems like it should be nearly trivial to implement a spreadsheet in it that would use a appropriate SQL backend this way.

Well, but spreadsheets have a grid feel instead of a table feel and follow grid rules instead of table rules.


That's generally true, though good spreadsheets make it possible to implement worksheets, or ranges of worksheets, that obey table-like rules to a greater or lesser extent, and the particular features highlighted in resolver one suggest that it does so far more than most out of the box (in ways that allow columns and rows to act like table columns and rows, and even allow worksheets to work like views backed by some set of other worksheets.) At least, that's what I infer from the description of worksheet formulae on the resolver one home page [resolversystems.com] :

Worksheet formulae

Resolver features formulae for worksheets as well as for cells; this allows a single formula to fill a worksheet with values calculated from one or more other worksheets. Result worksheets calculated in this way will be updated correctly as the input data grows or shrinks; this method also diminishes the incidence of single cells with incorrect formulae, since there is no need to mechanically specify the formula for every cell in the worksheet.

Maybe Spreadsheets are NOT for Nerds? (1)

Tablizer (95088) | more than 5 years ago | (#20786709)

But you are talking about a half-ass query language. I think that "true nerds" wouldn't even use spreadsheets, but a somewhat normalized database. It is easier to process data when it is "row-atized" such that you wouldn't have a different column for each region or product or month instance like one often does in spreadsheets, but rather a single product category/location/month code/indicator as part of a row. (dBASE and relatives were great at ad-hoc data chomping, by the way. SQL-based DB's assume too much formality in my opinion for ad-hoc work.)

Spreadsheets are an electronic version of accounting grid paper and meant to emulate the paper world. But true geeks leave paper representations behind when it suits the problem better, using a "relativity engine" to deliver the needed view via math-like transformations. Spreadsheets are not very transcendental, even if you do improve the formula propogation.

Thus, "nerd spreadsheet" is possibly a contradiction.
     

Re:Misuse of spreadsheets (1)

Jeff DeMaagd (2015) | more than 5 years ago | (#20783353)

The difference is that a lot of people know how to handle a spreadsheet, even my parents can handle them. Databases are somewhat arcane, that's one of the things that I've never really tried hard at learning. Microsoft Access was probably the most notable attempt at making it easy, but the nerd crowd certainly frowned on that. Even if it was good, I think they'd frown on it.

Re:Misuse of spreadsheets (1)

Tablizer (95088) | more than 5 years ago | (#20784437)

The difference is that a lot of people know how to handle a spreadsheet, even my parents can handle them

Until they over-use them and get into a jam. Then they call on us techies to help them make their contorted mess act like a database.

Microsoft Access was probably the most notable attempt at making it easy

It has way too many gotcha's for the average user. Sure, a lot of stuff is just a click away, but so is getting into a jam.
             

Re:Misuse of spreadsheets (1)

DragonWriter (970822) | more than 5 years ago | (#20784723)

Until they over-use them and get into a jam. Then they call on us techies to help them make their contorted mess act like a database.


This seems to be something that resolver one is aimed directly at, since a big selling point of its representing everything in Python is enabling IT staff to easily extract business-user-created spreadsheet logic and transfer it to other systems.

Re:Misuse of spreadsheets (1)

voidspace (875081) | more than 5 years ago | (#20784441)

Although in spreadsheet circles there are a lot of people saying 'access is the new excel', meaning that people who were previously creating horrible monster spreadsheets are now creating horrible monster access apps...

Just found a new way to sleep at work (3, Funny)

russ1337 (938915) | more than 5 years ago | (#20782999)

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 [slashdot.org] .

Python (0)

Anonymous Coward | more than 5 years ago | (#20783077)

And the code is IronPython rather than VBA.

IronPython is not a language!

Re:Python (1)

LiquidCoooled (634315) | more than 5 years ago | (#20783177)

Neither is VBA ;)

Spreadsheet, Or... (1)

Nom du Keyboard (633989) | more than 5 years ago | (#20783117)

There are some other cool things it does -- allowing cells to contain objects, and allowing spreadsheets to back-end websites.

Is this a spreadsheet, or a poor man's database?

Re:Spreadsheet, Or... (1)

Hatta (162192) | more than 5 years ago | (#20783161)

Is this a spreadsheet, or a poor man's database?

What's the difference?

Re:Spreadsheet, Or... (1)

mr_mischief (456295) | more than 5 years ago | (#20783589)

I'd say it's a poor man's database reporting system, perhaps.

Picture this scenario. Put your functions in one sheet, lock that sheet (if you can), and distribute a screen-based app in the default sheet. Every time the end-user updates a value in a query cell, the DB gets queried, the data gets transformed and formatted, and the results get updated. Need to update the app? Just force a transfer of the new "spreadsheet" file to all the clients.

Something like this might also make a custom time tracking or trouble ticketing system dead simple to throw together, too. Things like that have never really fit into a spreadsheet comfortably before, but they tend to contain lots of tabular data.

Re:Spreadsheet, Or... (1)

nuzak (959558) | more than 5 years ago | (#20784963)

I in fact maintain a couple reports that do exactly this. It's not exactly real-time (the query takes 10 minutes to run), but generating a new set of charts is just a matter of hitting the "refresh query" button.

You want real-time reports on streamed data, something like MOODSS [sourceforge.net] is probably the ticket.

Re:Spreadsheet, Or... (1)

ResolverSystems (1163669) | more than 5 years ago | (#20784045)

The metaphor is a much more programmable spreadsheet. The focus of the product is giving user an environment in which to manipulate data, not store high volumes of data or process transactions. Spreadsheets are frequently used to front-end databases, for data collection, data analysis, data loading, and ETL, which is well within the design intent of the product.

Does it run on Linux? (1)

pembo13 (770295) | more than 5 years ago | (#20783173)

Seems like a fairly on-topic question. Anyone know the answer?

Re:Does it run on Linux? (1)

sapone (152094) | more than 5 years ago | (#20783247)

In theory, it could be able to, since it's implemented in IronPython which runs fine on Mono. OTOH, their Website states that currently it only runs on Windows, possibly because they use parts of .NET that are missing in Mono. Or maybe there are some native parts too. They'll consider other OS if interest should arise.

Re:Does it run on Linux? (1)

Aladrin (926209) | more than 5 years ago | (#20783261)

IronPython works on Linux, so this probably does as well. Since it's not actually released, there's no much real info out yet. Sign up for the Beta and come back and tell us.

Re:Does it run on Linux? (1)

kiatoa (66945) | more than 5 years ago | (#20783459)

If it doesn't you could try "Scheme in a grid" http://siag.nu/siag/ [siag.nu] (supports scheme, tcl and a C like extension language). I've used it but must admit I usually resort to chicken scheme + sqlite for any data processing needs that go beyond what an ordinary spreadsheet can do.

Other direction (0)

Anonymous Coward | more than 5 years ago | (#20783179)

http://common-lisp.net/project/cells/ [common-lisp.net] is a dataflow extension that provides Common Lisp with classes where instances of the class have properties (slots in lisp parlance) that can be calculated like spreadsheet values.

Hex handling (1)

hedley (8715) | more than 5 years ago | (#20783239)

Importing and manipulating hex would please me no end.

H.

Great Idea (1)

declining (1163481) | more than 5 years ago | (#20783241)

This is a really interesting idea. If you think about it, every spreadsheet is a computer program. Excel is probably the most widely used development environment in the world. And it sucks. Big time. Watching the screencast, it looks like this is a great halfway house between bad, ad hoc, spreadsheet development, and a traditional IDE. The choice of Python as the language is a great idea - it's much, much easier for someone than VBA, and it's much more semantically powerful. I'd be interested in discovering whether it works existing Python and .NET libraries.

Re:Great Idea (1)

ifreakshow (613584) | more than 5 years ago | (#20783317)

They mention that all standard python libraries should work.

Re:Great Idea (1)

ResolverSystems (1163669) | more than 5 years ago | (#20784173)

We agree, and would slightly add to the comment above: a mash up of a traditional spreadsheet, a traditional IDE, and an integration framework. We currently support existing pure-Python libraries (e.g. not Python-wrapped C libraries) and .NET libraries. We are working to solve the interface and integration issues between IronPython and CPython, but this is a non-trivial development task (which we see as important to both our own product and the Python community at large).

It sucks when users over use it, not otherwise. (1)

GreggBz (777373) | more than 5 years ago | (#20784521)

Really, besides the laugh we had the other day, Excel does not suck. It's does a lot of things very very well. Just don't try to use it beyond what it's designed for.

I used to work in the finance department for a very large company, and I was inundated with Excel. People used it for everything and loved it.
The only hurdles come when someone tries to do something that's grossly inappropriate. That notion comes from finance people who love it and try to do everything with it. Sometimes they succede, sometimes it was ridicules. I don't fault Excel for that.

I Just think about basic command line stuff I use everyday. With bash you have sort, awk, grep, sed etc.. You can do very much the same things with Excel, only sometimes much more easily and with instant visual results.

Cripes I'm a Unix admin and I pine for Excel on Linux. OOCalc is missing ohh.. I don't know decent graphing, pivot functions etc..
I still find myself doing complex sorts, replaces, etc.. with excel ^H^H^H^H^H(ehh. OOCalc) because it's just easier.

That and the data is in a portable compatible format (not just a static text file) that anyone can pick up and continue to use, look at my formulas etc.. without much trouble.

Re:It sucks when users over use it, not otherwise. (1)

Doctor Faustus (127273) | more than 5 years ago | (#20785213)

The only hurdles come when someone tries to do something that's grossly inappropriate. That notion comes from finance people who love it and try to do everything with it.

That's because they have complicated analysis to do, and tend to think an awful lot like programmers do, but really have no training in appropriate tools to use for such things (or, frequently, the tools themselves). An "advanced" spreadsheet is a really good idea, but I think it should targeted toward accountants as much as programmers. With a little hand-holding from the software (mainly, making things visible that we programmers are used to thinking of in the abstract, which spreadsheets are good at, anyway), something on the border between spreadsheet formulas and functional programming could be a big help for them.

Re:It sucks when users over use it, not otherwise. (1)

voidspace (875081) | more than 5 years ago | (#20786729)

Which is exactly what Resolver hopes to do - sit in the gap between spreadsheets and programming. Making it easy to make the jump from formulae to simple functions to full blown object oriented programming...

Seems like Ken Tilton's Cells with GUI. (0)

Anonymous Coward | more than 5 years ago | (#20783323)

I *think* it's gonna be cool (1)

exploder (196936) | more than 5 years ago | (#20783375)

[quote]I haven't yet got my hands on Resolver, but here's an example of what I think that will mean.[/quote]
I said "WTF?" and stopped reading right there.

Real Interesting point (1)

gubol123 (933609) | more than 5 years ago | (#20783429)

is that this is the first time i am seeing a demo developed in silverlight. Yeah, i know, there are lots of demos on MS site. But this is the first time i am seeing somebody using SilverLight for some real demo on their own site. is this the sign of things to come? Time will surely tell

Seems kinda cool to me. (1)

cad106uk (1163635) | more than 5 years ago | (#20783435)

I had an interview with these people about 18 months ago (didn't get the job) but I thought there product was pretty cool. Its basically a simple spreadsheet that allowed you run an IronPython script in each cell. So you can run your spreadsheet with all the power the Python and .NET can give you ... say you wanted your spreadsheet of investments to update against a stock exchange web site every 30 seconds

Lotus Improv / Quantrix please (2)

WillAdams (45638) | more than 5 years ago | (#20783463)

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

Re:Lotus Improv / Quantrix please (1)

rcs1000 (462363) | more than 5 years ago | (#20783559)

Frankly, this looks like the nearest thing to Lotus Improv...

Re:Lotus Improv / Quantrix please (1)

voidspace (875081) | more than 5 years ago | (#20784133)

Resolver goes some way to solving this problem. Not only can you name cells (like Excel) but it makes it very easy to index worksheets and cell ranges using header row /column name.

you are looking for a "database" (0)

Anonymous Coward | more than 5 years ago | (#20783567)

this is just another VC whore I reckon

Windows Only (1)

cmacb (547347) | more than 5 years ago | (#20783591)

From the website:

Please note that Resolver is currently a Windows-only application . While we have no immediate plans to produce versions for other platforms, if there is enough interest then that will change.


There may be some exceptions, but I haven't found any... Once a bloger, journalist, programmer, and I'm sure lawyer, goes to work for "the Borg" they lose all sense of objectivity.

Why in this day and age would someone want to lock themselves into yet another Windows-only application?

I would avoid this thing like the plague. Even if Linux hasn't taken over the desktop, there are certainly enough Apple users these days that OS portability should be BUILT-IN to the design process from day one.

The whole point of an OS is to isolate the application from the hardware. But what good does that do us when so many new applications are designed to work with only a single OS, and that single OS is designed to work with only one type of hardware? Has our industry gone mad?

Re:Windows Only (0)

Anonymous Coward | more than 5 years ago | (#20784289)

I wonder if it will run on Jython? Then it could run on pretty much any platform, plus allow you to leverage pretty much any Java library. I'd guess IronPython is probably pretty much tied to .NET (i.e. Windows) though, or they would have just written it in Python. Might be fun to try and port it though, if you could get access to the source code.

Re:Windows Only (1)

voidspace (875081) | more than 5 years ago | (#20784401)

The big killer for this is the third party grid component we use which, (unsurprisingly) is pretty sophisticated. This is currently Windows only and looks like it would be a bitch to port.

The core model classes will run on CPython - and the server has been tested with Mono on Linux, so we definitely have it in mind to port to Linux. The target market though is (well - at least was when Resolver was formed) the financial services market, where Windows is still ubiquitous. .NET was actually chosen as the development platform before IronPython was chosen as a development language.

We're already pushing (beyond) the limits of what the grid component can do though. When we're rich enough we'll be looking at writing our own grid, and at that point it will definitely be cross platform. As I said, the server version is already cross platform.

Re:Windows Only (1)

multipartmixed (163409) | more than 5 years ago | (#20786413)

> I would avoid this thing like the plague. Even if Linux hasn't taken over the
> desktop, there are certainly enough Apple users these days that OS portability
> should be BUILT-IN to the design process from day one.

Building portability into the design does NOT equate building a final product for zero dollars.

Once the code is written you still have alternate packaging, distribution, and -- especially -- testing. None of which are free, and may not be economically viable.

Mac OS on Intel being the PERFECT example there. You don't think Intel compatibility just sprang from the turtle neck, do you?

A Better Headline (1)

mdmkolbe (944892) | more than 5 years ago | (#20783605)

"Spreadsheets with First-Class Functions and Objects"

This is just a spreadsheet with the ability to put functions and other objects into cells. It's a good idea, but there is no need to dress this up in marketspeak. We understand techno-babel just fine here.

Re:A Better Headline (1)

ACS Solver (1068112) | more than 5 years ago | (#20783777)

Is "techno-babel" when a thousand geeks all speak different languages?

homebrew (1)

kisrael (134664) | more than 5 years ago | (#20783725)

Not reading TFA, it reminds me a bit of my custom db/ui solution that I use for generalized information storage: links, books and movies I watch, developer notes, etc... it some web-based Perl CGI and is, in effect, a big old flat table database, the columns defined by text files, and it auto-generates a convenient form with the usual spattering of HTML input types...

Spreadsheets of limited application (0)

Anonymous Coward | more than 5 years ago | (#20783999)

If I wanted one that'd take functions or objects for most given languages, I could probably write the basics in a weekend. This is like the MS powershell thing that allows users to pipe objects; a solution in search of a problem.

The Analyst: the first Nerds spreadsheet (1)

itsybitsy (149808) | more than 5 years ago | (#20784273)

There was a Spreadsheet made for the CIA by Xerox that would easily be the Nerds Nerd of spreadsheets as it enabled full access to the underlying programming language, Smalltalk.

Here are some links to the old version and newer developments.
http://wiki.cs.uiuc.edu/VisualWorks/The+Analyst [uiuc.edu]
http://www.mojowire.com/TravelsWithSmalltalk/DaveThomas-TravelsWithSmalltalk.htm [mojowire.com]
http://www.sunless-sea.net/wiki/SmallTalk [sunless-sea.net]
http://www.google.ca/search?num=100&hl=en&newwindow=1&q=%22the+analyst%22+xerox+smalltalk&btnG=Search&meta= [google.ca]

Hockey stick curve? (1)

Chris Shannon (897827) | more than 5 years ago | (#20784505)

No matter how good a tool is, it's only as good as the raw data.

  1. $500 per month in sales after 6 months.
  2. ???
  3. Profit! $320,000,000 per month after 12 months.

These people need a reality resolver instead of a spreadsheet replacement.

Re:Hockey stick curve? (1)

voidspace (875081) | more than 5 years ago | (#20785333)

Uhm... are you taking those figures from the screencast? I think you'll find that was a spoof just to illustrate Resolver in action... :-D

VBA already does this... (3, Insightful)

gillbates (106458) | more than 5 years ago | (#20784811)

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.

And for Gantt charts... (1)

legirons (809082) | more than 5 years ago | (#20784861)

And for Gantt charts, there's a program which lets you express each task in python code (including whatever calculations, remote data, or whatever that it needs to get data from)

http://faces.homeip.net/ [homeip.net]

they have their work cut out for them (1)

Locutus (9039) | more than 5 years ago | (#20785261)

and here is why, even moderately smart programmers are more comfortable with a spreadsheet than a database or full blown application. Example which I believe still applies today:

I was a member of a "club" of techies who were investing in the stock market in the 1996 timeframe. We cycled the clubs officer positions through the club membership so everyone knew what others were doing and how. The 2nd year, I got the Treasurers position and my job was to collect "investments" at each meeting and provide a overall club report and reports for every member's position/investment in the club. I was handed a spreadsheet with tons of data entry cells sheets to fill in data. I could have cleaned this up but hey, this was the age of the internet right. So I build a SQL database to handle the accounting, wrote code to drive a CGI interface to a web server and wrote scripting to trigger updates on stock valuation and triggers to update the database on changes. It was all accessible from a web browser with a login. And very repeatable. It worked great after the 3rd months meeting and for the remainder of the year. Because it was cross platform, it would run on anybodies computer and did not need to be on the internet.

Here's the kicker( finally ). The next Treasurer was the guy who started the club, owned his own business, was a Windows software engineer who's product he built over close to 10 years and was a signal processing kit(PC and software appliance ). He knew what I was saying when I described the package I'd built to do the books but he wanted none of it. He wanted the latest report and then he write a spreadsheet to handle the task. And for every meeting from then on until the end of the club 2 years later, we were constantly correcting data in the spreadsheet and sometimes, corrections required pulling out paperwork from previous months meetings.

There is a fools familiarity with spreadsheets which people find comforting. They will go to great extremes to try and get the spreadsheet to work for what they are trying to do. Great extremes. And with the plethora of Neanderthal-ish computer users out there who think they are computer guru's because they can do "=(A2+B2)" in MS Excel, it is a long long road to get movement outside of the spreadsheet.

I just found out a buddy has taken on a 2nd job and is trying to build a business out of it. He's under charging to get experience in more aspects of the field and to construct a spreadsheet to "automate" the task(s). He's thinking that the business will grow around the "application"/spreadsheet.

So I think the title should be, "Jon Udell on the Geek's Spreadsheet" because the nerd is really not that 'into' the technology to really know or want to work outside of a standard spreadsheet. IMO.

LoB

Something like MS Access? (2)

FranTaylor (164577) | more than 5 years ago | (#20785493)

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.

Re:Something like MS Access? (1)

Rick Genter (315800) | more than 5 years ago | (#20786917)

I may be a diehard Red Sox fan, but I still cheer when a Yankee makes a good play.


Then you aren't a true Red Sox fan...

Not much new for Openoffice users ... (1)

kubusja (581677) | more than 5 years ago | (#20785827)

Python scripting was possible for a long time for Openoffice users ...

Spreadsheets Cause Brain Damage (1)

tom's a-cold (253195) | more than 5 years ago | (#20785845)

Like other posters said: half the time they're busted, denormalized lame-ass substitutes for databases. The other half of the time they lead to convoluted algorithms that would be expressed more simply in code. Spreadsheets are the shits-- logic and presentation layer tightly coupled. The only value they give is in sortable and filterable views, and grid controls on a webpage will do that for you nowadays.

Scheme on a Grid, anyone? (2, Interesting)

PaulBu (473180) | more than 5 years ago | (#20786289)

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/ [siag.nu]

Paul B.

InstaCalc (1)

kazad (619012) | more than 5 years ago | (#20786347)

(shameless plug)
I'm a nerd as well, and built an online calculator/spreadsheet for myself. It's a new take to an old problem: instant answers, inline units (MB, GB), and shareable results. Yes, it handles 850 * 77.1 and more [tinyurl.com] .

Thought you might find it useful.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>