No DSL is 'human-readable' as such

March 23, 2010

One of the popular advantages attributed to using domain-specific languages is that they're 'human-readable'. This label is highly misleading because there is no such thing as a human readable computer language of any sort, DSL or otherwise.

Despite decades of AI research, we cannot instruct computers in natural language; it is too slippery and imprecise. As a result, all languages used to specify things to computers have specific semantics and are not simply 'plain English'. Even if you try hard to use English words and English phrases, what you wind up with is something like legal language (and for much the same reasons); the words may be English, but everything has a specific technical meaning and you cannot truly understand what programs actually do or write them until you understand those technical meanings.

(One of the heights of these attempts to be as English as possible is COBOL, and that didn't work; you still can't completely understand or write COBOL programs without knowing COBOL, and the process created an ugly monstrosity.)

DSLs are not magically exempt from this because they are small and simple (if they are). Just like other computer languages, you cannot really understand what any DSL 'program' does without learning the DSL itself, which is to say learning the specific technical meaning and semantics that the DSL attaches to words and phrases (and punctuation and so on). To the extent that a DSL looks 'human readable' without this learning, it's fooling you; you don't truly understand what things mean, and if you believe otherwise you can go horribly wrong.

(Sometimes you get away with it, just as much as you can sometimes hack away in a full programming language that is vaguely familiar to one that you already know. But that's not something to rely on; for real production work, as opposed to quick test hacks, you're going to need to learn the DSL.)

I believe that there are real advantages to DSLs, including being easier to read. But this is not the same thing as being 'human readable', and pretending it is distorts discussions of DSLs and their advantages (and drawbacks). Specifically, using a DSL instead of some alternative doesn't mean that people magically don't have to learn the DSL because they already understand what it does; they don't, not really.

(I alluded to this in passing in an earlier entry.)


Comments on this page:

From 193.201.135.244 at 2010-03-23 05:12:49:

Couldn't agree more that an English-like programming language is a huge mistake, I offer AppleScript as the exemplar (http://userweb.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf , pdf) and what is baffling is that people continue to make that mistake.

David

From 87.236.251.199 at 2010-03-23 07:20:16:

I think this misses the point.

First of all, "human-readable" as a term doesn't imply that something is automatically comprehensible, merely that it is relatively comprehensible by a human. You can't read English either without learning the semantics attached to words, grammar, punctuation, etc. and yet it is clearly human-readable.

Second, I don't think the goal of DSLs is to be "human-readable" (though obviously it is more or less a given that they are). DSLs are designed to be as expressive as possible for the domain at which they are targeted. That is to say that you can implement what you need in the domain with as little verbosity and duplication as possible and that you can make needed changes in as small an area as possible. Further, a well-designed DSL should be as clear as possible (by virtue of being limited in scope and of mapping naturally to the user's own domain of knowledge.

None of this is to suggest that a DSL is appropriate in all contexts where a configuration file might be used, however.

Written on 23 March 2010.
« Why I exploit Python to shim modules for testing purposes
One reason why 'zpool status' can hang »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Mar 23 00:03:01 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.