The world in a clock

When one is comparing languages, it is fruitful to take a small example program, and implement it in multiple languages. The previous examples were a little too hard, and few stepped forward with example code of their own. So let's take it down to rock bottom simplicity. The written specification:

1) draw a standard 12 hour clock with 3 hands: hour, minute, and second. Show the current time in GMT. Move the hands by jumping from second to second. Make the clock look like this:

If you were try to program this in C / Win32 environment, you would find that it takes hundreds of lines of code, and reading hundreds of pages of manuals. You can't just draw on the screen, you gotta first create a window, and then create a graphic context, select brushes, etc.. Since Win32 had no concept of frame rates or animation, you had to manually create an offscreen context, draw into the offscreen world, then refresh manually. It was extremely hard to get a smooth frame rate. That very cumbersome system made Bill Gates the richest man in the world, because it was adopted by 95% of personal computers. That environment was a reliable but clunky platform to program on, but it took hundreds of hours to get up to speed. Professionals didn't mind, but amateurs sure struggled.

Instead of picking a language for this clock project, let's imagine the optimal language for this task. How short can the program get? What is the absolute minimum number of things you have to specify in order to get the result? Every program is information given to the computer sufficient to make it produce the result. We know that you must specify the following:

1) the center, radius, color, thickness of the circle
2) the color of the interior
3) the relative length of the second, minute and hour hands
4) the color and stroke width of the hands
5) the current time in GMT, converted to hours, minutes, seconds
6) the update interval for the refresh of the screen (1 frame per second)

so there are 5 colors, and 14 numbers that one must supply in the code. Let's assume the system will tell you the current time, so the OS will supply the 3 time numbers. So there are 5 colors and 11 numbers in your code (at the minimum). An optimal language will just have 11 numbers in the program code. However, there is no available language that can accomplish this task with just 11 numbers in the code, for the simple reason that library functions like sine and cosine invariably use radians as the units, and converting hours into radians involves additional calculations and numbers. Every time you add another number into your code, there is another chance for error. The numbers given above are really the specification of the program, and can be presumed to be correct. Any program that has only these constants, and no other calculations will probably have zero errors. If the only thing in your code is the specification you were given, then no errors can happen. This is the whole thrust of the declarative language movement: if your code is merely a reiteration of the specification, then almost no errors can occur. 

So the absolute smallest would look like:

draw a circle with center CX, CY with radius R fill with interior_color, stroke with border_color
draw the hour hand from at the proper angle, color and stroke thickness
draw the minute hand at the proper angle, color and stroke thickness
draw the second hand
refresh the clock display every second

So we can with mathematical precision, state that the minimal code is 5 lines, and should have 11 numbers and 5 colors. Since no general purpose language will be perfect for drawing clocks, we can get approach perfection. But how close can we get? That is a very interesting question. Our measurements show that Beads is the closest to optimal language that we have seen.

But step back for a second, and let's catch up to today's graphical standards. Nobody wants to see stripped-down programmer generated graphics. Let's take the same clock, and jazz it up with some bitmap graphics:

This clock has one more dial in it, the date at the bottom, So there are 4 hands, the day, hour, minute, and second hands. If you are given the background artwork consisting of the watch background, and the 4 hands, you should be able to draw a much nicer looking clock. This is far more representative of what people want to build. The previous clock is pathetic in comparison.

So now, the program needs at a minimum the center on the background image for the hour, minute, second hands, the center for the day hand, and then 4 more images and the origin point of the hand inside those images. The total information needed is therefore:

5 image file names (CANVAS, day, hour, min, second hands)
center_x, center_y for hour/min/sec hands in background image (2 numbers)
center_x, center_y for day hands in background image (2 numbers)
the origin xy point inside the 4 hand images (8 numbers)
a refresh rate of 1 tick per second (1 number)

This much nicer looking clock has the same amount of information in it as the stripped down analog clock! Even though this project is a 100 times nicer looking, it is basically the same program and should be no longer than the previous version. How short a program could exist for this project? Clearly it is 6 lines of code:

1) draw the background image
2) draw the day hand bitmap at the center with the proper angle
3) draw the hour hand
4) draw the minute hand
5) draw the second hand
6) refresh the screen every second

I look forward to seeing your submissions, which I will add to this blog and comment on. Given that the fancy bitmap version is only 1 line more of code (to draw the day hand), this should be a trivial project. You can download the graphics so you can try this task in your favorite language:

But it isn't a trivial project in many languages. Just packaging bitmap artwork into a program, and making available during execution is a trick. HTML5 can load images across the web, with no effort, but when you are talking about a product that can run offline, it gets much trickier. I assert that this small example shows so much of what is wrong with modern development systems, where the minute you ask for external resources to be packaged a whole can of worms is opened.