Omath hopes and dreams
From Omath
First, a historical note; omath used to be called Tungsten. That name is now only used internally to refer to the kernel implementation. You get the idea. --Scott 03:28, 28 October 2005 (EDT)
Dror's Dreams and Hopes
What a khutzpah it is to step into somebody's personal Wiki and type my hopes and dreams regarding a project in which I have not written even a single line of code. Yet one, that's what wikis are for, and two, I sincerely hope and dream to contribute to Tungsten in a significant way later on. Thus it is important that my hopes and dreams be clarified to myself and to others. These hopes and dreams will likely guide my own direction of work and may perhaps influence others.
One property of dreams is that they aren't always internally consistant. There is a risk that this dream is an example. I hope not; and in any case, we should at least strive to fulfil as much of it as can become reality.
Tungsten should be an open source, open documentation and open spirit system for doing mathematics by computer; it's openess should be its source of strength. It should be extremely easy for beginners yet it should have a powerful engine. And the route from the absolute novice to the engine hacker should be very well documented and inviting. We (the authors and future authors of Tungsten) have some feel and some opinions about math and about programming. We keep learning new things and yet we will never learn enough. Hence if our program is to have a general appeal, it must be open.
Other computer math systems are around. But none is as open as ours will be and hence, ultimately, none will be as strong.
I see Mathematica as a pretty good computer math system (except it is for (much) profit, hence closed, hence bounded). Thus Tungsten should start as a loose Mathematica emulator. It should be close to Mathematice to make migration easy, yet we should not waste effort on making every bit of Mathematica code run on Tungsten, for ultimately, we want to be way better.
Tungsten should start with an extremely well documented evaluation kernel and parser, a small library of operators such as Map, Apply, Function and their likes and a rudimentary notebook interface.
The notebook interface should be implemented in javascript and run within a web browser. The In boxes should be resizable text boxes like the one I am typing into right now, as I am editing this wiki page. The Out boxes should be in standard html, and graphics should be in png. The kernel should run within the browser as a Java program. Hence the first Tungsten user experience will simply be viewing a web page. Yet as a Java program Tungsten will be secure, and hence we will have almost no problems with trusting outside source code. To allow for file system and external program interactions, there will have to be an out-of-browser Tungsten interface as well, but the secure and the less secure parts of Tungsten will be clearly delineated.
At first pass, the kernel will not load all Tungsten routines into the browser. Rather, these will be designed as individual Java programs that will be loaded via http as needed. There will be no unique Tungsten server; it will be easy for Joe of the University of East Ambulapcha to write kernel-integrated java code to implement homology over <math>{\mathbb Z}[t]</math> and to put his code on his own web server. He will be able to state that his code requires Jane's code for finding the Smith canonical form of a matrix, available from the web server of the university of west Ambulapcha. There will be a good namespace mechanism that will guarantee that Joe's programs will see Jane's symbols, but if the user only wanted to see Joe's programs, Jane's will remain hidden.
Knowing and anticipating that things will change, there should be a wiki-style standard that will encourage Joe and Jane to keep all old versions of their work online; thus if Jane changes her interface (or if we do!), Joe will have the option of connecting to the new interface or explicitly stating that he wishes to work with Jane's routines of a certain vintage.
All of Tunsgten will be so well documented and tutorialized that people will have no difficulty replacing original parts, even the kernel, with better written counterparts. Thus even if our first implementations will be primitive, eventually Tungsten will beat the competition even when measuring speed for core operations.
Perfect is the enemy of excellent. We should always remember this and do things even if we don't quite know how to them right the first time around.
