I started the current Java version of C.a.R. in 1996, I think, right when Java came up. The first version was in Java 1.0 and the versions followed Java through its history. Much has changed since then on the Java front, mostly to the good. The environment became faster, richer and more reliable. The graphics became smoother. Some changes in the language required a major rewriting, others just added new features and were most welcome.
There had been prior versions of C.a.R., or rather predecessors. The first dynamic geometry program I wrote was for the Atari ST in C, mimicing an object oriented style. That was in 1989 or so. When the Atari ST and its GEM operating system died a sudden death, the program was ported to OS/2, at that time crawling rather than running on the first IBM machines designed for DOS. OS/2 soon lost the battle against Windows. The Windows version was more a rewrite than a port. It was in C++ already, so object orientated programming was easy. Without OOP, programming was a pain. The Windows version was rather advanced already, but not to compare with the Java version we have now.
I have to admit that I did much of this programming for the fun of it. At first, I did not think this would be such a useful tool, and consequently did not drive the features too far. I also had other things to do, working in mathematics. The Java version was lying in the drawer for about two years, when Hans Fischer asked me, why I did not pursue that project. He argued that existing programs had no nice and easy interface, and he probably was right.
Hans was especially interested in the Web. Java is a great program for doing things for the Web. While Flash seems to outrun Applets nowadays, the combination of Java applications and Java applets cannot be beaten easily. Consequently, much of the programming efforts went into exports, web export as well as the graphics export. Recently, LaTeX export was added.
The intended user community were lower level schools. However, there is now considerable usage in high schools or colleges. The implementation of non-euclidean gemetries in C.a.R. shows that this program can be used on a high level too.
The main problem is, wether geometry is still taught at all. Today it is vanishing in favour of analytic geometry. This is an old discussion that I like to acuminate as computing versus thinking. Both have their values, and neither is better than the other. But as a math professor, I find that the students are lacking logical skills. It is quite hard to get them to abandon their habit to compute everything, neglecting the accompanying logical reasoning.
One should mention that there are lots of other communities in dynamic geometry. In Germany, Euklid is very widespread. Once teachers are used to one program it is quite understandable that they stick with it. In the US, we have Geometers Sketchpad which is really a great program to publish in the Net. And in France, there is Capri. In Austria the great GeoGebra enhances the connections between algebra, analysis and geometry, and thus meets the requirements of many teachers directly. These programs may have other intentions, but learning one program closes the mind for another even if it is free.
C.a.R. is not really a free program. No program is free. However, this is not understood by many users. I would rather pay for a program that I want to use if it works for me, than to get it for free and get a shabby interface and a lacking documentation. The true costs of a software arise while learning and using it. This is the Apple Macintosh wisdom. Nevertheless, being free helped C.a.R. a lot. Schools do not have money even for the cheapest of licenses. And, of course, C.a.R. is free and at the same time useful and easy to use.
One thing I want to point out is the enduring support by the community. A lot of the translations have been done by other people, whom I thank here cordially. I also thank all those Web pages that use C.a.R. A special thank to Erik’s maginzine CarZine and all its authors.
When I took up the work, it became sort of a self runner. Users asked me to add this or that feature or to simplify a procedure. Moreover, the documentation took a lot of time, much more than the programming. I am currently rewriting the English pages, and it will take me numerous hours and days to complete. Since I am busy with other things, the progress does not go as fast I wished. The programming itself is fun, the documentation is the hard work.
Adding features is something I do not like to do, but it is unavoidable. Every new feature makes it harder to use the program. Good programs are simple and do what they are supposed to do. It is a hard work to make a program easy to use. In the case of C.a.R., this process is not yet finished. Many features the experts requested, got, and are now using, is simply a nuisance for the avarage user. This is one of the reasons, I hide features under non-obvious procedures sometimes.
Or let me phrase it another way. It is better to make a complicated procedure stable and easy to use, than to add another problematic feature.
Many users judge a program by the beauty of the interface. For a long time, C.a.R. was not the most beautiful program around, better than some others, but with a straightforward and simple user interface. I tried to keep that simplicity while beautifying the look. But the program itself became more and more advanced, as features accumulated under that simple hood. So I do understand those who ask for a more advanced and slick interface. I welcome Eric Hakenholz’s work in that direction. I am still not sure, if this is going the right way. Maybe, removing features would be better after all. In any case, I will try to simplify usage as much as I can.
Keeping the program open sourced, is one way to ensure a quality development in the future. Eric has shown that everybody can take the code and extend it. Since I will at some tome stop developping C.a.R., publishing the source is the only way to keep the project alive.
I should probably not be afraid of code forging, but I am. At least, as long as I feel that there sould still be some extensions in the core functionality. Since the file format is connected to the core code, this is a real danger. The choice of XML helps in this matter since the format is clearly readable, even human readable. So it should be possible to sort things out, if versions become different some day.
Finally, let us wish C.a.R. a prosper future! Thanks to all, who contribute to this!