DSL examples - thrills and spills: "Data lend me your ear!"

The final chapters of Olsen's book Design Patterns in Ruby made my lips dry. I hadn't checked ahead, but Olsen mentions mid-text what's to follow. In getting there and reading about the Interpreter pattern and DSLs, I do hope this does not prove a one-off date. Olsen's book IS brilliant (and besides Ruby looks so dynamic across the dance floor), but the examples used were tinged with anti-climax and prompted a reality check.

Olsen's examples DO illustrate the principles, like most things worthwhile they need deliberate reading, but they DO deliver. So what's up? Well, the examples presented are taken from the world of IT (file backup). Yes, I know... well what do you expect! I had hoped for a DSL from a less technical domain; something left-of-centre, something that traverses the HUMANISTIC - MECHANISTIC divide. This is where the definitions of domain, DSL and the craft of caring and programming can (possibly) provide some useful insights.

For decades the literature and projects have focussed upon nursing languages. Communication relies on language of course. Even the absence of messages - verbal, non-verbal or other - tells us something. In health and other professions great emphasis is placed upon communication skills. We have to listen actively. How we listen - the constraints, what we deem as significant, and what is subsequently recorded and retained defines our care domains.

The domains that are the subject of DSL are specific, which explains how they can be implemented in some 50-70 lines of code (this also says something about Ruby). In contrast, within Hodges' model those four domains may as well be galactic quadrants they are so broad. Regardless of this (non-trivial) issue, standing at the nexus of h2cm the question needs to be asked (and is constantly being asked by health & informatics communities):

How good a listener can the MECHANISTIC ear be?