Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Software

Jon Udell on the Nerd's Spreadsheet 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.
This discussion has been archived. No new comments can be posted.

Jon Udell on the Nerd's Spreadsheet

Comments Filter:
  • Can it... (Score:5, Funny)

    by O('_')O_Bush ( 1162487 ) on Friday September 28, 2007 @10:25AM (#20782707)
    Multiply 850*77.1 correctly?
    • Re: (Score:3, Funny)

      by Daimanta ( 1140543 )
      And if you can, how do you maintain compatibility with Office Excel calculations?
      • Re: (Score:2, Funny)

        Well, it uses the new, patent-pending doublecalc technology. It's the equivalent to doublethink for calculations. Doublecalc allows the same result to be both 65535 and 100000 at the same time, thus remaining compatible both with conventional math and with Excel.
    • Probably, but I wouldn't be surprised if it fails on 0.1 [python.org]
  • 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: (Score:1, Insightful)

      by Anonymous Coward
      Life is a grid with a logic tree, dude.
      • by Teun ( 17872 ) on Friday September 28, 2007 @10:37AM (#20782903)

        Life is a grid with a logic tree, dude.
        It's called Tetris.
      • Actually, life is more like an arbitrarily large number of interrelated grids, with lots of complex logic. This is why more complex stuff is usually shunted off to databases. Or should be. I've seen far too many Excel files that would be way more useful in a database of some sort.
    • by LWATCDR ( 28044 ) on Friday September 28, 2007 @10:38AM (#20782911) Homepage Journal
      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.
    • "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
    • Re: (Score:2, Insightful)

      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
    • I worked at one of those too. Excel for everything. Annoyed the crap out of me.
    • Re: (Score:2, Informative)

      by Ed Avis ( 5917 )
      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.
  • by quanticle ( 843097 ) on Friday September 28, 2007 @10:29AM (#20782761) Homepage

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

    • by PJ1216 ( 1063738 ) * on Friday September 28, 2007 @10:32AM (#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: (Score:3, Interesting)

      by Hatta ( 162192 )
      Why use a database or spreadsheet? Why not something like the R Project [r-project.org]?
      • by garcia ( 6573 ) on Friday September 28, 2007 @10:58AM (#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: (Score:2, Insightful)

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

          • by Bodrius ( 191265 )
            The parent's post still applies:

            Is a nerd's time somehow less intrinsically less valuable?
            Or does 'the context of a slashdot article/submission' intrinsically mean that the nerd in question does not have a 'job in the real world' and therefore has infinite amounts of free time to use the most complex tool for the simplest job?

            Granted, it looks really cool and fascinating, and likely it is perfect for a specific type of software development, but one might as well ask 'Why not use Mathematica instead of a spr
        • by jbengt ( 874751 )
          "and most people utilize Excel as a database rather than a spreadsheet . . ."

          In the engineering company I work in, most people use Excel only as a way of formatting.
          It drives me nuts when I see someone tapping away at their calculator, only to type the result into a cell Excel!

      • Re: (Score:1, Offtopic)

        by kalirion ( 728907 )
        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.
    • 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

      • Re: (Score:3, Funny)

        by Yetihehe ( 971185 )

        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(); !
    • 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.

      • If all you're doing is arithmetic, then why are you using this? Wouldn't a traditional spreadsheet be just as useful?

  • by OverlordQ ( 264228 ) on Friday September 28, 2007 @10:30AM (#20782781) Journal
    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?
    • 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
    • by C3c6e6 ( 766943 )
      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! :-)
      • 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.
    • 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.
    • Didn'T RTFA, but is this guy reviewing a product he didn't even use or see being used, so in effect only from the marketingspeak that came in the announcement?
  • 2D programming? (Score:3, Informative)

    by 16384 ( 21672 ) on Friday September 28, 2007 @10:33AM (#20782827)
    Organising code on a spreadsheet... I guess it will resemble Befunge [wikipedia.org]
    • I had never heard of Befunge before, but I can tell you that you just gave an ex-Forth programmer a full-body shiver.
  • by winkydink ( 650484 ) * <sv.dude@gmail.com> on Friday September 28, 2007 @10:36AM (#20782883) Homepage Journal
    and allowing spreadsheets to back-end websites

    munge them?
    hack them?
    copulate with them?
    • Re: (Score:2, Funny)

      by Anonymous Coward
      No, back end. See Jack Thompsons latest court files for details.
  • by Tablizer ( 95088 ) on Friday September 28, 2007 @10:39AM (#20782925) Journal
    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.
           
    • by voidspace ( 875081 ) on Friday September 28, 2007 @10:44AM (#20783013) Homepage
      "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: (Score:3, Informative)

      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

      • by Tablizer ( 95088 )
        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 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 sprea

          • 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 muc
            • But you are talking about a half-ass query language.

              Says who? I haven't seen how they implement the particular feature, but Python is a rather full-featured language.

              I think that "true nerds" wouldn't even use spreadsheets, but a somewhat normalized database.

              A spreadsheet is essentially a UI which can be wrapped around different storage engines, including an RDBMS. "Spreadsheet" and "database" aren't mutually exclusive alternatives.

              It is easier to process data when it is "row-atized" such that you wouldn't

        • by Tim C ( 15259 )
          the user cannot add columns quickly

          See now, that all depends on the UI, doesn't it?

          For me, alter table add (column_name type [constraints]); is quick and easy, but then I'm used to tools like sqlplus. In a graphical tool, it could be as easy as right click on table -> add column -> enter name and optionally type (or accept some default, say varchar2(4000) or even CLOB for Oracle). Hell, you could even design it so that it looks just like a spreadsheet, with "spare" columns after the last one, and you
    • 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.
    • Why even stay in column,rows.You abstractize the concept of (column) and assign tags to objects,with TAGNAME{number} being its property and managing relations between tags as you wish.
      basically you can add tags as basic dimensions or optional categories for anything in the database.
  • by russ1337 ( 938915 ) on Friday September 28, 2007 @10:44AM (#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].
  • 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?

    • by Hatta ( 162192 )
      Is this a spreadsheet, or a poor man's database?

      What's the difference?
    • 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 trou
      • by nuzak ( 959558 )
        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.
  • Seems like a fairly on-topic question. Anyone know the answer?
    • by sapone ( 152094 )
      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.
    • by Aladrin ( 926209 )
      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.
    • by kiatoa ( 66945 )
      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.
  • Importing and manipulating hex would please me no end.

    H.
  • 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 discoveri
    • They mention that all standard python libraries should work.
    • 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
      • 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 bash you have sort, awk, grep, sed etc.

        Yeah, if it would take much more than a "sort", a spreadsheet might make sense.

        Then again, I so rarely have to do this kind of stuff one-off that it doesn't really make sense for me. I'm much more likely to have something that I need solved in a generic way. The 10 lines of Perl (or Ruby, etc) that it might take to model will be harder to write than a spreadsheet, for most people, although I'm not as comfortable with spreadsheets as I am with programming. But th

  • [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.
  • 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
  • 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
  • by WillAdams ( 45638 ) on Friday September 28, 2007 @11:13AM (#20783463) Homepage
    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

    • by rcs1000 ( 462363 ) *
      Frankly, this looks like the nearest thing to Lotus Improv...
      • by jefu ( 53450 )

        Ah Improv. Best spreadsheet I ever used. Though there was this odd thing (advance? don't remember) that took improv one step further and did some great data modelling tasks, but I could only get an evaluation copy. And then it seemed to go away.

  • 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

    • > 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 PER
  • "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.

  • 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...
  • by gillbates ( 106458 ) on Friday September 28, 2007 @12:33PM (#20784811) Homepage Journal

    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, 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]
  • 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 overa
    • At some point, an organization realizes that they either don't have the training to be able to keep working from a spreadsheet, or they need something more powerful anyway.

      So they buy FileMaker Pro.

      Which means, they essentially have a bunch of different, interesting views, with some (very) limited scripting, all ultimately centered around one flat table.

      (Yes, I know there are later versions which actually function as relational databases, but most FileMaker stuff I've seen is around version 5 or 6. Most peo
  • by FranTaylor ( 164577 ) on Friday September 28, 2007 @01:14PM (#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.
    • 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...
    • Firstly, there are other major commercial players. FileMaker, for instance -- which I have to work with occasionally.

      Second, FileMaker (and Access) are object lessons in why you shouldn't do it this way. Like you said, the SQL engine has flaws, the scripting language is junk, and the GUI is quirky and weird, but you like the report stuff.

      Were this done right, you could keep the reports, and replace everything else. This is how KOffice seems to be implementing this, or trying to -- Postgres or MySQL can be u
  • 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.

  • by PaulBu ( 473180 ) on Friday September 28, 2007 @02:06PM (#20786289) Homepage
    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.
  • Wolfram [wolfram.com] called; they want their concept back.
    • Back before we first got involved with Mathematica 1.0, I was already looking for something that would put real calculations in table cells but Wolfram became wedded to the notebook format that was arguably the only practical solution to being cross platform in the 1980s.

      On the Mac more was often promised but rarely delivered. There was a very early "spreadsheet" called Trapeze which allowed you to lay out a multiplicity of typically smaller grids which always appealed to me more than the idea of forcing un
  • The idea reminds me of "Cells" by Kenny Tilton. From the site [common-lisp.net]:

    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.

  • Every time a user changes a Resolver spreadsheet, the software generates Python code expressing their desires;

    Oh yeah? How does Python express hot, naked babes and a sixpack?
  • Hilarious! Joel wrote flippantly about this exact intellectual exercise here:

    http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html [joelonsoftware.com]

    People who are Smart but don't Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. [...] For example, they will say, "Spreadsheets are really just a special case of programming language," and then go off for a week and write a thrilling, brilliant whitepaper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful."

Life is cheap, but the accessories can kill you.

Working...