XRVG is actually a response to different problematics:
Some fractal shapes, as the Mandelbrot set, correspond to rasterizing algorithms, and are so usually generated by a mathematical formula iterated for each pixel of the image. While a large variety of rendering techniques exist, the produced structure of the image is somehow always imposed by the mathematical formula. A typical fractal work consists then in exploring a set of varying formula to find interesting shapes. You cannot specify from scratch the shape you want to obtain.
Other fractal algorithms exist to compute fractal shapes. For example, Iterated Function Systems recurse geometric transformations on shapes to produce a fractal attractor approximation image. But again, algorithms are quite simple, and not easily extensible.
In response to this feeling, I started to develop several little scripts to implement simple recursive algorithms and generate SVG files (see Blog). I soon got a disparate set of programmatic tools to compute and generate vector graphics, which became tricky to organize. I then decided to refactorize these scripts in a programming toolkit, which so yields to XRVG.
Nearly every programming toolkit that you may find, in any programming language, instanciates shapes with absolute geometrical coordinates. What that means is that if you want to do graphics programming with them, you rapidly get lost in a list of basic drawing primitives with lots of numbers, without being able to recover the abstract compositional content of the graphic.
Actually, a graphic is foremost a composition of basic shapes and color. It is not their absolute values (that is absolute spatial and color coordinates) but their relations that matters. This is even more true because our visual perceptive chain processes its inputs in a relative way, as paradoxical visual games highlight it.
As a consequence, XRVG strives to get rid of these absolutes, by using shapes and functions as numerical patterns to compute shapes and composition. Thus, if you want to draw five circles in a regular way, you must be able to do it without using trigonometric formulae to figure out where these circles have to be drawn. Instead, you just need to use a first circle and "sample" it five times to have subcircle centers.
I started to implement XRVG in Tcl with the XOTcl extension. It was a good choice, mainly because I was quite familiar with these tools, and because I wanted a programming language both object-oriented (for shapes) and functional.
However, I rapidly became stuck by the lack of a memory garbage collector, since a typical XRVG script involves several hundred thousand objects. I switched then for Ruby, mainly because I wanted to learn it for Ruby On Rails. It was a quite pleasant switch, because while fitfulling my previous requirements, it also comes with very easy metaprogramming facilities, plenty of tools, and an active community. From then I have sticked to it, even if it is a bit slow. XRVG would be a good start to learn Haskell, or make a first big implementation in Lisp, though :-).
As for output, SVG choice was quite trivial, as an XML free and widespread (not enough?) vector graphic data format.
And yet, XRVG before all consists in a set of algorithmic means to produce graphical composition, and is thus, to some extent, technology-independant.
XRVG can be considered as a small contribution to the software art movement, by the fact that it consists on novel and customized tools to explore a different kind of artwork.
I also like to think that XRVG may sometimes be seen as a (very modest) tentative to instanciate Kandinsky theories on painting composition abstraction based on shapes and colors composition rules.
XRVG is under the MIT licence. I hope some people (in particular the Ruby community) might find it useful.
A number of similar (and far more advanced) initiatives already exist:
Some other very interesting links