Possibly, but we think there significant differences in our approach Resolver expresses a spreadsheet as a Python program. The code pane shows the entire spreadsheet as an executable Python program. User code, data and system code are cleanly modularized. The result, in our experience, is dramatic improvement in programmability and modeling power.
Certainly a nice console window and debug output window would improve, in our opinion, most existing spreadsheet applications. However, this will not fundamentally change the interaction patterns between the cells, user code, and application code, nor the architecture of the application. One of the reasons why we can deploy Resolver spreadsheets to the web so easily is that they are Python programs, one of the benefits of this architecture.
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).
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.
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.
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.
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.
Slashdot Mirror
Possibly, but we think there significant differences in our approach Resolver expresses a spreadsheet as a Python program. The code pane shows the entire spreadsheet as an executable Python program. User code, data and system code are cleanly modularized. The result, in our experience, is dramatic improvement in programmability and modeling power.
Certainly a nice console window and debug output window would improve, in our opinion, most existing spreadsheet applications. However, this will not fundamentally change the interaction patterns between the cells, user code, and application code, nor the architecture of the application. One of the reasons why we can deploy Resolver spreadsheets to the web so easily is that they are Python programs, one of the benefits of this architecture.
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).
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.
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.
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.
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.