Spreadsheet Amanuensis

Disclaimer

Please do not email me about this project without reading the disclaimer above.

1. Microsoft is getting a little too much market share with Excel.
2. Excel can’t exploit multiprocessors. It does not run on workstations or servers.
3. Collaborative features of Excel are primitive.
4. Spreadsheets will become the way to have the end user customise parts of a boilerplate program. For example, customers will provide tiny spreadsheets to calculate taxes or commissions.
5. Everybody should write at least one spreadsheet engine in their lives, just to learn how they work inside.
6. David Pollack’s Integer, (which handles floating point doubles just fine) which did some of these wonderful things, is no more.

1. It is an amanuensis i.e. it generates the source for a Java program to compute it and then compiles the code on the fly with the resident sun.com.javac.Main class. It does not bother with an interpreter at all. Not only do you sidestep the overhead of an interpreter, you automatically exploit the latest Java optimisation technology for the code you generate. You regenerate source and recompile before every execution if there are any changes. Let’s hope you have fast enough CPU (Central Processing Unit) to make this not too onerous. You don’t have automatic recalc the way you do in a conventional spreadsheet. The code you generate just calculates. It does no display, data entry or file i/o. One advantage of this approach is it becomes trivial for the end user to add new functionality to the spreadsheet. Spreadsheet functions are simply garden variety Java static methods.
2. If you want to put some hair on your chest, instead of generating Java source code, generate the class file byte codes directly in RAM (Random Access Memory), then use a custom ClassLoader to load them directly from RAM, without ever creating any *.java or *.class files on disk. For hints on how you might do this see JASM.
3. The code you generate is multithreaded. You can partition the spreadsheet calculation into threads that can be run in parallel, without object locking. This means you can maximally exploit every additional CPU.
4. The spreadsheet is not a standalone program, but rather a JavaBean class, with optional Swing user interface. It designed to be just another component, like a TextArea, that you can plug into your own apps, or customise and plug into your own apps. It becomes trivially easy to add new functionality into your spreadsheet or to integrate your spreadsheet into other applications, quite unlike a desktop spreadsheet.
5. In version 2 you might think about how you could avoid recompilation when the only changes were to numeric literals, not the formulas.
6. In version 3, using RMI (Remote Method Invocation), you can have several people viewing and possibly even updating, a spreadsheet simultaneously. You could do it with peer to peer, with all copies complete and updating themselves, or with a central copy, accepting transactions and just serving result changes for the part of the grid of current interest to each client. In any case, the idea is to keep the traffic between the copies to a bare minimum. This way you could actually execute the spreadsheet on some super server with 256 CPUs (Central Processing Units) and blow everyone away with the calculation speed. It would be far faster than any desktop spreadsheet.
7. In version 4 you can start thinking about how to import and export Excel spreadsheets. That way you could develop your spreadsheets in Excel, then export them to your spreadsheet engine for production.

standard footer

	This page is posted on the web at:	http://mindprod.com/project/spreadsheet.html
	Optional Replicator mirror of mindprod.com on local hard disk J:	J:\mindprod\project\spreadsheet.html
	Please read the feedback from other visitors, or send your own feedback about the site. Contact Roedy. Please feel free to link to this page without explicit permission.
	Canadian Mind Products IP:[65.110.21.43] Your face IP:[52.15.42.61]
Feedback	You are visitor number