[junke]

> But thanks for the example, it's fun to see how data modeling is done in other languages.

Franky, this example upset me because this is the typical "LISP has only lists and symbols" example. On the first hand, the format is not deprecated: you could write a simple parser today and extract the data back. But on the other hand, it reinforces those core myths about Lisp having no real datatype, no strings, etc.

[brudgers]

I wasn't trying to upset anyone. I came across the example in the cited document a few years ago and had an epiphany. What I find elegant is that it does not have all the conceptual overhead of a 'real' database even today. In historical context it does not have all the overhead of the primary alternative COBOL (there weren't widely available relational database systems in 1978). The other thing I found striking was that it was code I could write myself without reference to a pile of documentation.

I mean the parser is something like:

  (defun appt:appointment-date (appt)
    (first (first (appt)))
  (defun appt:appointment-start-time (appt)
    (first (first (rest appt))))
  (defun ...

In fairness, I don't really worry about winning the language war. Partly because I don't draw a big distinction between Clojure and 'Lisp', or at least not one that comes down to more than choosing one or the other based on the runtime that makes sense and the skills of the people writing the code.

Anyway, what I found interesting about the code years ago and yesterday was how lightweight it was. There's nothing inherently wrong with storing appointments in Zulu time, but if I'm talking with Lundstrom it's easier if we both say '10:45'. Reflecting that business logic in the data may make sense in the context. In other contexts it might not.

[junke]

Thanks for the clarification, I don't mind the actual format and its simplicity; I understand what you mean about being lightweight. What bothers me is that I often see questions or statements about Common Lisp which contain factually wrong statements. The most notable is "Common Lisp has only lists (e.g. hash tables are built using cons cells)"; another one is "you have to write in All Caps". And your example is indirectly confirming that, as shown by the reply you got, saying "here is how we do in Clojure" and "it's fun to see how data modeling is done in other languages" (that was really depressing to read). Sorry for the "upset" part.

As an aside, since I can customize the readtable in CL (which is not considered useful in Clojure), I added a single entry for "#i" (and read-char to ensure it ends with "nst") to read the exact same data as in Clojure; but I got an error about invalid dates; it just happens that the Clojure example does not actually contain valid RFC3339 dates (I also tried to with Clojure => invalid date format).

[brudgers]

Like I said, I appreciate Clojure and I took the comment as someone's expression of enthusiasm for the language. Part of the design rationale for Clojure is to improve the lives of Java programmers and Common Lisp isn't usually a viable option in such a context and hence there's less justification for a comprehensive analysis of its features. If someone is more or less committed to the JVM, the numerical sophistication of Common Lisp doesn't change the criteria for choosing a language very much, if at all. Like a lot of things, it depends on context.