Lambda the Ultimate

From the discussions:

I've noted with great interest the evolution of XML specs, in the Web services realm, away from the monolithic and towards the granular and "composable." This seems to me a fundamentally correct way to attack complexity. And XBRL seems monolithic, not composable, hence my reaction.

One of the most commonly used mechanisms for composition in XML is embedding, with namespaces being used to distinguish one vocabulary from another in the composed document. The end result is documents which may contain a great many "optional" components, which can create problems in itself (the HL7 model in its latest incarnation moves away from optional elements in favour of OO-style polymorphism, in an attempt to resolve some of these problems).

Jon points towards the amazing proliferation of WS-* specs as an example of greater granularity and composability. It's certainly true that one way to "attack" complexity is to break it down into smaller pieces; but if all you can do with those pieces is put them back together again then at best you have a "build your own monolith" construction kit.

Most real PLs give you more than that. They give you the ability to make simple pieces out of simple pieces, through mechanisms such as recursive definition and parameterisation. One of my favourite examples is the "top level" of HaXml's XML parser, which reads:

xmlParse :: String -> String -> Document
xmlParse name = sanitycheck . papply document emptySTs . xmlLex name

Now that's composition.

Seems like an example of marketing and positioning of large software corporations to me. This is all supposed to be manageable through buying "wizards" embedded in the IDEs like Visual Studio, Eclipse, etc.

None of these efforts have an appealing "language" perspective from what I can see. It's all apparently done through the magic of "SOAP Headers".

What kind of language is that? Languages are to communicate. I know of no one who can communicate effectively about the WS-*. No one except the snake oil salesmen.

XBRL isn't designed to be hand-written, and that level of simplicity is not a virtue in the design space it targets.

I get the sense that the appeal of the character basis of XML is that it enables an easy form of inspection in language systems that are typically not very open, especially in their support for aggregated objects.

XML would probably not have gained much appeal in language systems like Lisp, Smalltalk, etc. whose binary objects, especially aggregates, are well supported by the system for inspection.

XBRL isn't designed to be hand-written, and that level of simplicity is not a virtue in the design space it targets.

I do get a bit tired of hearing this particulary excuse, or variations thereupon, being trotted out to justify inscrutable or intractable formats. Particularly, I think it fudges an important issue, which is that many XML vocabularies are not only syntactically verbose but highly repetitious - they require you to spell things out, in longhand, over and over again. What they lack is not so much "simplicity" as style.

Based on the few examples I've seen, XBRL looks to me a little like XHTML would look if it didn't have CSS: each item of information has to be tagged with numerous attributes indicating its format, encoding, precision and so on. What I don't see is any way of defining a few common attribute sets and then re-using them throughout the document. Perhaps it can be done, but browsing the spec I didn't see an obvious mechanism for it.

Readability and writeability by a (sufficiently smart) human being seems to me to be a good rule-of-thumb desideration for language design. Can one think in XBRL?