Random Art and the Law of Rotten Software

Since the death of my old web server my Random Art has not worked. Bringing it up to date and installing it on the new server was a nightmare in software management. But it was worth it. The new Random Art runs the random art program inside your browser!

I implemented the old Random Art in 2005 with ocaml and cduce. Cduce is a programming language for XML which statically checks correctness of produced XML. I thought that nothing could be better than a web site that has an a priori guarantee of 100% complicance with strict HMTL. Those were the days of idealism.

Well, in 2010 it turned out to be quite impossible to reinstall Random Art on the new server. First of all, the current version of cduce is incompatible with the one from 2005. In addition, the old version of random art relies on old ocaml libraries that are not available in current Linux distributions, so I cannot easily recompile it. If I really wanted to install the old version, I would have to install an antique Debian system from 2005, but then I would suffer from old security holes. There must be a software equivalent of the second law of thermodynamics, let’s call it the Law of Rotting Software:

“All software eventually fails, even if it you leave it alone.”

So it was clear that I should junk cduce and use something sane, like Django. (I know there is ocsigen, but as we say in Slovene, even a donkey steps on thin ice only once). I separated the ocaml code that computes random pictures from cduce and reimplemented the web site in Django. The site was up and running in no time! Except that all pictures were uniformly gray. It took me a week to figure out that this was caused by a change between ocaml 3.10 and 3.11 in how they treat mutable record fields inside function closures. It is still not clear to me exactly what the change is because I am not able to produce a small example that shows the difference.

I wanted to make the new site more user friendly by allowing users to generate their own random pictures. They would have to compute images inside their web browsers because I cannot afford a cloud of servers. So I decided to try Jake Donham‘s amazing ocamljs compiler that compiles ocaml to javascript. It worked, after a couple of days of making sure that the javascript code was equivalent to the ocaml code. I had to fix the pseudo-random number generator (which broke compatibility with the old random art), and remove a number of ambiguities about the evaluation order of arguments (ocaml evaluates  f x y in an undefined order, but usually right to left, whereas Javascript evaluates the arguments in f(x,y) from left to right). I am amazed at having 1200 lines of ocaml code run inside a browser.

Anyhow, I hope you will enjoy the new web site. Now I just have to make it work under Internet Explorer, which does not support HTML5 canvas element that I use for drawing (I suppose I just have to get Google’s excanvas to work.) Also, I recommend Google Chrome over Firefox because its javascript engine is way faster.

8 thoughts on “Random Art and the Law of Rotten Software

  1. Well, I am not to keen on publishing the part that generates images. That’s where the real meta-artistic effort went in. But I plan to make another version that will be rendered instantly in javascript, and will allow pictures to be “mated”.

  2. Andrej, I feel your pain! I embarked on the futile project of making a G3 Power Mac my web server, and even if I succeeded in the end the task left me somewhat scarred. It’s not so much that software itself decays, it’s the dependencies that diverge relentlessly. No matter how pure we write our code, it always depends on something else, and if we don’t port our code it will be left behind, eventually.

  3. You probably either know this by now or don’t care, but Unicode characters outside 7-bit ASCII produce different results on the Javascript version from the server version.

    If my experiments and calculations are correct, you can fix this by calling unescape(encodeURIComponent(…)) on the input string before running the Javascript version. This converts the string to an explicitly UTF-8 coded sequence of bytes, which is the same format that’s being used by your OCaml version on the server.

Leave a Reply

Your email address will not be published. Required fields are marked *

48 + = 53

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>