I wrote IronPython in Action for Manning Publications. Working with a publisher greatly improved the book, but it is still a long and arduous process. I wrote up my experience with Manning (good points and bad points):
http://www.voidspace.org.uk/python/articles/technical-writing.shtml
"the fact that logic and presentation are tightly coupled is the *strength* of spreadsheets" - except when you want to add code, when you have to jump into a completely different interface.
With Resolver the view is just as tightly coupled, *plus* the view includes a code editor (and the code runs as a normal part of the spreadsheet execution rather than living in a separate world).
Well - in the screencast we demo the product, so none of it comes from any 'announcement'. Resolver is in use with several customers and a bunch of beta testers (probably including Jon Udell by now - so maybe he will have more to say about it!)
Certainly in Resolver (and probably other spreadsheets) you can do operations on whole rows and columns... Resolver also provides lots of useful ways of working with small chunks of data (tables if you like) - cell ranges.
There is an example of this on the Resolver Hacks website:
http://www.resolverhacks.net/exotic_datatypes.html
It defines a custom 'magnitude' datatype that controls how it appears on the grid and how it behaves in calculations when used in fromulae. You are free to use any Python or.NET datatype of course, as well as define your own.
Hmmm... not substantial differences in my experience (of developing Resolver). Ocassional bugs and some differences (garbage collection and the string datatype being unicode for example) - but programming with IronPython is really programming with Python.
Yep. With Resolver you can create new datatypes (that use operator overloading to control how they interact in formulae and how they are represented on the grid) - and then use them in formulae.
Sure - programming in the grid is functional programming. This is great.
Resolver allows you to easily use libraries (whether Python or.NET assemblies) from within your spreadsheet, as well as put whatever code you want at certain points within the execution of your spreadsheet. This is where OOP comes in - some functionality is best encapsulated within objects that can be used within cells or spreadsheet code.
As DragonWriter says, Resolver is a bridge between the spreadsheet model and programming.
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...
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...
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.
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.
"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.
"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.
Slashdot Mirror
Whichever you prefer. I approached a couple, but Manning "bit" quicker than anyone else so I just pursued it with them.
Working with a publisher, and in particular a copy editor (although they can be hired professionally) can greatly improve the quality of a book.
I wrote IronPython in Action for Manning Publications. Working with a publisher greatly improved the book, but it is still a long and arduous process. I wrote up my experience with Manning (good points and bad points): http://www.voidspace.org.uk/python/articles/technical-writing.shtml
"the fact that logic and presentation are tightly coupled is the *strength* of spreadsheets" - except when you want to add code, when you have to jump into a completely different interface.
With Resolver the view is just as tightly coupled, *plus* the view includes a code editor (and the code runs as a normal part of the spreadsheet execution rather than living in a separate world).
Well - in the screencast we demo the product, so none of it comes from any 'announcement'. Resolver is in use with several customers and a bunch of beta testers (probably including Jon Udell by now - so maybe he will have more to say about it!)
Certainly in Resolver (and probably other spreadsheets) you can do operations on whole rows and columns... Resolver also provides lots of useful ways of working with small chunks of data (tables if you like) - cell ranges.
There is an example of this on the Resolver Hacks website: http://www.resolverhacks.net/exotic_datatypes.html It defines a custom 'magnitude' datatype that controls how it appears on the grid and how it behaves in calculations when used in fromulae. You are free to use any Python or .NET datatype of course, as well as define your own.
Hmmm... not substantial differences in my experience (of developing Resolver). Ocassional bugs and some differences (garbage collection and the string datatype being unicode for example) - but programming with IronPython is really programming with Python.
Yep. With Resolver you can create new datatypes (that use operator overloading to control how they interact in formulae and how they are represented on the grid) - and then use them in formulae.
Sure - programming in the grid is functional programming. This is great.
.NET assemblies) from within your spreadsheet, as well as put whatever code you want at certain points within the execution of your spreadsheet. This is where OOP comes in - some functionality is best encapsulated within objects that can be used within cells or spreadsheet code.
Resolver allows you to easily use libraries (whether Python or
As DragonWriter says, Resolver is a bridge between the spreadsheet model and programming.
"convoluted algorithms that would be expressed more simply in code" - which is kind of exactly the point of Resolver. :-)
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...
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
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...
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.
.NET was actually chosen as the development platform before IronPython was chosen as a development language.
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.
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.
Making spreadsheets unit testable is certainly one of the aims of Resolver.
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.
"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.
"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.