What is a Little Language?

"Little Language" is actually a technical term from the academic
computer science world. But little languages themselves are some of
the most powerful practical tools available for specialized tasks.

Here are some examples of little languages:

Procmail

cfengine

Makefiles

Apache Configurations

sed

m4

Shell languages

Lexical analyzer generators

Parser generators

Hardware Description Languages

Some example borderline languages are:

Awk

Postscript

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.

Little languages are not for everyone, but if you have a
specialized task for which there are few existing tools, then creating
a little language may be your best choice.

An example application

Biologists frequently compare microscope images side by side in
their academic journals. To create these multi-frame images they
frequently spend hours laying them out by hand in their favorite
commercial tools (Illustrator, PageMaker, Canvas, whatever). However
it might be a good idea to create a language for specifying these
types of figures, and have a computer program generate these figures
automatically. The language might include methods for constraining the
distance between images, the scale of each image, the overall size of
the figure, which images go together, the label text, the colors of
borders, etc. Then a geometric solver could fit all the images
together in such a way that they all satisfy as many constraints as
possible. A graphical program could display the figure, and allow the
user to hand-tune the individual images before finally producing
Postscript output. All figures created with the system would have a
uniform appearance, and fit well together. The biologists could save
time previously spent meticulously drawing borders, and ensuring that
all images had equal spacing and layout. To give you an example of one
idea of what this language might look like I have the following
completely fictional example:

Is creating such a language, and the associated graphical program a
task that an individual biologist could take on? Probably not. But
neither is NIHImage a
tool for manipulating individual microscope images. Still the utility
of this type of tool is so obvious that an organization devoted to
biology decided to produce it. Will they decide to produce a figure
language? Probably not, most biologists don't even recognize the
amount of time they spend doing this task, though they frequently
complain about poorly created figures. Such a language would save many
biologists time, and avoid a lot of complaints about ugly figures that
show poor quality results if it existed.

What other tasks might you use little languages for?

Modeling financial derivatives, describing text formats,
automatically checking your web site for common problems, accounting,
filtering network data, describing graphs, creating graphics, or
controlling a Internet enabled laundry machine. Any specific task that
needs to be easily configurable, and doesn't have existing tools is a
candidate for a new little language.

Sometimes little languages don't even need to be their own
language. In Common Lisp and Scheme for example, the powerful macro
utilities can create "sub-languages" within the main language. For
more on this type of programming see
Paul Graham's book
On Lisp
or the other great information on his web site.

How can you create a little language?

Creating a little language involves a variety of design and
implementation issues that many programmers have no experience
with. Creating a lexical analyzer, and parser is a relatively easy
task compared to deciding on the structure of your language, the
meaning of statements in the language, and a good way to express the
task. Still if your task is a common one for your company or
associates, the effort can pay off.

Before creating a little language you should get a firm grasp on
the problem it will help you solve. Since the problem will be one you
deal with frequently, you will probably have a good idea of the issues
already. Consider the kinds of data your language will need to
express, and the types of computations it will need to carry out. Will
sophisticated mathematics be necessary (as in Postscript) or will you
need to be able to express dependencies (as in Makefiles)? Perhaps you
need to describe timing, or the sequence of certain events. You might
want to process many files at once, or all files of a given type. You
might need to read and interpret input data from devices or network
connections. Whatever your task, you will need to know what kinds of
data you will process, what kinds of operations you will support, and
what kind of structures fit your task.

If you have a task which you do frequently perhaps there is an
existing little language to solve it. If not, perhaps you'd like to
discuss how to go about creating one. You can contact me to find out
how I can help you with your task.