It should be clear from the tutorials, and the paper describing
StageTools, that there are several things that make
CenterStagedifferent from other mathematical packages like
Maple. The most important of these are the ability to link input devices like sliders and check-boxes to values in the objects being displayed, and the ability to link one object to another.
The first of these means that when the user changes a value, the objects update automatically. This makes manipulating the parameters of the object very easy, and removes the need for the user to know complicated commands in order to see the results of his changes. For example, students can be presented with a demonstration that allows them to concentrate on the mathematical effect of their changes, rather than on the syntax and programming issues involved in making their changes.
The second of these makes it easier to specify certain types of objects, for example a tube around a curve. The author of a
CenterStagedemonstration does not need to work out the parameterization for the tube itself, but can simply describe the base curve and the cross-sectional shape of the tube;
CenterStagedoes the rest. Additionally, if the curve changes, say due to a change in a slider, then the tube will update accordingly. This helps to maintain the natural connections between the various objects. The main paradigm of programs such as
Mapleis an algebraic one; the underlying idea in
CenterStageis to treat the objects as having geometric, not just algebraic, content.
During the development of
StageTools, certain basic decisions had to be made, like what language to use. An interpreted language was chosen because this offered several advantages. It makes prototyping and development easier, and avoids the machine-dependencies inherent in compiled code. It would make installation easier for users, as there would be no compilation necessary, with its associated need for libraries and other tools that makes installing new software a complicated process. It would make the resulting program more dynamic, in the sense that new code (e.g., new object classes) could be loaded in without recompiling the program.
The trade-off, of course, is that a compiled language offers superior speed, but the decision was made to sacrifice some speed for greater flexibility. The original need for
StageToolswas to make animations for the web, so the speed of generating a frame was less crucial, as it would not impact the final movie. It was only later that it became clear that
CenterStagewas also suitable for interactive work, especially in light of the recent explosion in processor speeds. Of course, converting the
StageToolsmodules to a compiled language would give a vast speed improvement. This is a substantial project that is unlikely to occur in foreseeable future.
The next decision was which language to use. At the time, there were two candidates: Perl or TCL/TK.1 While Perl was a more sophisticated (and faster) language, TCL/TK was the obvious choice for several reasons: first, its TK library allowed for the creation of the user-interface elements (like sliders and type-in areas) that
StageToolsrequired, while Perl had no such ability; second, TCL was designed as a tool language to be incorporated into larger projects, so after the prototyping was done, portions of the code could be compiled into it for improved speed; and finally, TCL is extensible in the sense that user-defined procedures automatically become commands in the language, so the language can be customized to suit any needs. This makes it possible to define commands like
Surfaceobject without having to write a separate parser; one simply defines the procedure to be executed by these commands and pass the entire object-definition script to TCL to be executed as TCL commands. This has the advantage of making a fully functional programming language available in the definition scripts as well. The user can include
if-thenor looping statements, set and use variables and arrays, and even read files or produce output in his definition scripts, all without any additional programming required in developing
StageTools. This flexibility has turned out to be very useful when
CenterStageis used to produce complicated objects.
A disadvantage of picking TCL/TK was that it did not have an object-oriented programming model at the time,2 so
StageToolsincludes an object-oriented programming layer on top of TCL.3 This is an additional speed trade-off, but has been well worth it in terms of programming flexibility. The various geometric object types (like surfaces and curves) are implemented through corresponding objects at the program level. Specialized versions of these geometric objects (like ruled surfaces or tubes around curves) are subclasses of the basic object classes at the program level. This makes it very easy to add new classes of geometric objects, as they will inherit all the important functionality from the parent class.4
Were this project to be started today, rather than in 1994, some of these decisions might have been different. For example, it would be wonderful to have a
CenterStage-type program written in Java that could be included as an applet in a web page for use by students on a homework or lab assignment where they work experimentally with some mathematical object. Now that Java has a 3D graphics library, it would be possible to write a Java-based replacement for
Geomviewthat would be sufficient for these needs.
Some would ask why it was necessary to write these programs when there are other mathematical packages such as
Maple. After having gone through the tutorial and read these materials, the answer is probably clear at this point. First, these programs do not have interactive input controls (sliders, and so on). Second, they use an algebraic rather than a geometric approach, so the linking of one object to another is much more ad hoc. Third, the graphics in these programs is not very interactive. For example, in
Mathematica, in order to rotate a 3D object, one must specify a new viewpoint by hand or through a cumbersome control panel, and then must recompute the graphic; this is not interactive. In
Maple, objects can be rotated interactively, but in order to change the object being displayed, one must enter commands to create an entirely new graphic; this is not very dynamic, either.
Another question some may ask is why pick a unix platform rather than a Mac or PC for this project? Aside from the fact that
Geomviewis only available under unix, there are other reasons. One must recall that in 1994, a 33 Mhz PC was considered reasonably fast, and hardware-based graphics acceleration was expensive. Now, 800 Mhz machines are common, and 1.4 Mhz clocks are available. Then, Microsoft Windows was still at the sub-standard
version 3.1,5 and the Mac OShad only just become multi-tasking with version 6. While things were improving on these platforms, they were not yet ready for serious graphics development. Also, the TCL/TK language, chosen for its flexibility and user-interface capabilities, was not available on microcomputers at that time.
Note that Java was just being developed by Sun, and had not
yet been licensed by Netscape and Microsoft for their browsers. Its
future was not yet clear, and in any case, it would not have
interoperated well with
This is not entirely true, as
This could have been distributed as a separate product, but
there are now half a dozen other similar systems available, so it did
not seem necessary. Most of these try to mirror the style of
You can look at the class definitions in
The first usable version of Windows, in my opinion, was