Just in Time for the End of the World: a Mayan Calendar Generation Program

OK, just kidding...my wife and I don't really believe that the world
is coming to an end at the end of the current Mayan Great Cycle.
And to demonstrate our optimism that we'll still be here after
December 21st of this year, we are finally releasing the first
version of our Mayan calendar generation program (written in
Clojure, of course).  Version 1.0.0 is available on GitHub at
https://github.com/hickst/mayancal.

The Mayancal program generates a PDF file containing an illustrated
Mayan calendar for the specified year (the default is 2012...just in
case). The earliest year available is 1900, but this should allow
most users to generate a calendar for their birth year.

The Maya developed a sophisticated calendar based on the
intersection of various cycles, especially the 260 day Tzolkin
(ritual calendar) and the 365 day Haab (a rough solar calendar). The
Tzolkin named each day; like our days of the week. There were 20 day
names, each represented by a unique symbol. The days were also
numbered from 1 to 13 (Trecena cycle). Since there were 20 day
names, after the count of thirteen was reached the next day was
numbered 1 again. Since 13 and 20 have no common divisors, this
system uniquely represents all 260 (13*20) days of the sacred year
with a unique number and day-name combination.

The Haab was a rough solar year of 365 days. The Haab year contained
named months called Uinals. These were 18 regular months of 20 days
each and one special five-day month called Uayeb. Days of the Haab
months were numbered 0 to 19. Each day had a number and day name
from the 260-day Tzolkin as well as a number for each day of the
Haab month (Veintena cycle). Using the intersections of these
cycles, each day can be identified by a four-tuple:
[Tzolkin number, Tzolkin day, Haab number, Haab month].

Using Clojure's infinite lazy sequences these interacting cycles can
easily be generated and combined together with an infinite Gregorian
date sequence (see the mcal.clj file in the source code). To
simplify the program, all sequences are synchronized to start at the
Gregorian date of 1/1/1900. Any given point is then found by
dropping the appropriate number of elements from the heads of the
synchronized sequences.

Some miscellaneous notes: Because of the many great public domain
images and icons used to illustrate the calendar, the output PDF
file tends to be rather large so you probably don't want to email
calendars to all your relatives for Christmas. Also, we've tried
viewing the calendar in Preview 5.5.3, Adobe Reader 10.0.1, Skim
1.3.22, and GoodReader for iPad 3.18.6 and we've seen a few
differences between these viewers. Only Adobe and GoodReader, for
example, were able to follow the embedded links and GoodReader had
trouble displaying the links on the last page.

As I said, this is version 1, so if you encounter any issues please
let us know. We hope that this toy provides you with some fun and
diversion from the more serious, real-world uses of Clojure.

EIPs in ROC

Randy Kahle has recently written a blog entry which artfully expresses the thinking behind the yearnings for a new ROC (Resource Oriented Computing) language. I suspect that most ROC users would be happy just to see a better syntax for module creation but, as Randy points out, a ROC language should provide a better way to conceptualize the information flow through the system.

I've thought for some time now that what's missing in NetKernel is an abstraction of the higher level patterns of information flow through spaces; an implementation of EIPs (Enterprise Integration Patterns) for ROC. EIPs in ROC could be made manifest in a couple of ways, the simplest being to express the pattern as a particular composition of existing space elements. This approach, however, strikes me as analogous to expressing a pattern in an assembly language without macros: too detailed and hard to repeat correctly. A more powerful solution would be to express some of the simpler EIPs in ROC by encoding them directly as new types of overlays. The most recent overlays, such as the Pluggable overlay and the Branch-Merge overlay, seem to be attempts to encapsulate such patterns of usage. Sadly, these fall far short of the simplicity and beauty that they could have if they were not mired in the grammar-less verbosity of XML. (1)

Please note that, by saying "patterns" (inherent in EIP above) I mean something more abstract and more encompassing than the existing recipes for the connection and interaction of spaces, which are labeled as "Module / Space Patterns" in the NetKernel documentation. While these recipes are a step in the right direction, their level of granularity seems too small to express anything but the simplest EIP. In addition, their descriptions focus on the mechanics of space interconnection and it's very hard to elicit how they can be composed into EIPs.

A new ROC language built around Enterprise Integration Patterns would allow ROC programmers to concentrate on solving their application problems by focusing on the high-level, logical flow of information through the system. Such a language would include, at a minimum, the ability to compose, connect, and visualize some base set of EIPs.  An additional ability to implement arbitrary EIPs would be extremely powerful but might require that the existing facilities to build modules and factories be enhanced, simplified, and canonized into a clean API (re: this forum discussion fragment). If the new ROC language were to eschew XML and to rely on a simple syntax, I feel this would be a huge win. Finally, I believe that a new language built around EIPs would greatly contribute to the usability and adoption of NetKernel and ROC.

1. It's interesting to speculate on the reasons why there are not more higher-level patterns and why they are not easy to spot in NetKernel's standard module. I think the principle of Linguistic Relativity is at work here; the idea that the structure of a language affects the ways in which its users conceptualize their world.

Why natural languages have grammars

This occurred to me after reading several NetKernel forum entries crying out for help with NK's "declarative syntax". I think there are some great ideas in NetKernel but the idea of burying your programming language within XML is not one of them.

<sentence>
 <np>
   <verb type="gerund" subject="true">Programming</verb>
   <pp>
     <preposition>in</preposition>
     <noun type="proper" acronym="true">XML</noun>
   </pp>
 </np>
 <vp>
   <verb tense="present">is</verb>
 </vp>
 <np>
   <determiner singular="true" indefinite="true">a</determiner>
   <noun>pain</noun>
   <pp>
     <preposition>in</preposition>
     <determiner definite="true">the</determiner>
     <noun>ass</noun>
   </pp>
 </np>
</sentence>