Intro

Also known as "domain specific languages" or DSLs.

My research interest here are as follows:

• What Little Languages could be used to ease the development of XML based applications?
• How can XML tools be used to develop Little Languages?
• Are there XML vocabularies, or common mixtures of vocabularies that could be further summarised by creating task specific languages.

See also XSLT for Code Generation

Definitions

HTML files, config files, shell scripts can all be classed as kinds of little languages.

Apparently the term was coined in this article: Jon Bentley, "Little languages", Communications of the ACM, 29(8):711-21, August 1986.

A domain-specific language (DSL) is a programming or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain. -- Domain Specific Languages

Little languages are also sometimes called Domain Specific Languages, they are highly expressive for a given type of problem, since they are usually made especially for that problem.

What can little languages do for you? By creating a little language especially to solve a common problem, you can switch your focus from debugging complicated programs written in a "big language" like C++. And since there are little languages specifically for creating little languages, you can turn your task into a layer cake of simpler tasks. --What is a Little Language?

Links and Discussion

Misc

• This paper on compiling little languages in Python notes that
  ...little languages, and the need to implement them, are recurring problems...Tcl was...developed to address the proliferation of little languages.
• Big annotated bibliography of DSL papers
• DDJ summary of the Lightweight Languages workshop
• Little Languages for XML describes prototypes for an imperative and a declarative language to manipulate XML documents.
• Matt Sergeant did a talk on XML-based little languages

C2 Wiki

C2 Wiki has a page on little languages: Some quotes:
One spin-off of the UnixDesignPhilosophy was the realization that it is easier to implement a task-specific language optimized for that task than it is to implement a general-purpose language optimized for all possible uses

Also: A related sort of little language is the little language that isn't designed with efficiency in mind at all. Instead, it's intended to save the developer time and effort by allowing her to express her intentions at a much higher level of abstraction.

I find this aspect particularly interesting, especially with regard to little languages constructed in XML.

Little Languages: Little Maintenance

Little Languages -- Little Maintenance (PDF).

Little Languages, tailored towards the specific needs of a particular domain, can significantly ease building software systems for that domain.

The above paper also notes that LLs are typically declarative. The first case study confirms my belief that LLs can be evolved out of sufficiently well-specified APIs, allowing the engineer to ignore the details of the actual API and other programming minutiae and work in more abstract terms that a closer to the real problem domain.

The paper also notes that an LL can often be validated more easily than a lower level implementation can be tested.

Little Languages promote separation between the language and its implementations: alternate code generators can be introduced without changing the language.

The paper includes some notes on how to develop a LL by analysing a problem domain, identifying the semantic concepts, and providing implementations of those concepts using a library/API

Little Languages and their Programming Environments

Little Languages and their Programming Environments.

We must learn to re-use all levels of language technology in the construction of little languages.

An embedded language is easier to extend than a stand-alone language.

An embedded language in their terms is one which shares similar/same syntax as the underlying language (e.g. their LL extends Scheme). I'd argue that the same would apply to XSLT based code generation: there's a very thin layer of implementation for the little language, meaning that it can easily be extended by exposing more of the underlying language, or otherwise taking advantage of more of its features.

Notes

Template languages are also LLs. These allow a web-designer, typically not well-versed in a programming language to develop user interfaces for an application. These template languages are typically converted into an underlying programming language, e.g. JSP->Java (APIs here are those provided with Java, and by the engineers, e.g. tag libraries).

A good chunk of the papers and discussions I've seen so far talk about compiler construction and similar details, focussing on the details of how to implement a little language. However if one constructs the little language using XML these details are (largely) resolved: use an XML parser. The code generation can then be handled using XSLT to generate the actual code, assuming much of the gritty details are handled in the supporting API.

If Web Services can be viewed as simple functions (data in, transform, data out) then presumably Web Service Choreography (or whatever term we want to apply to it) can be described as writing a program using those functions.