| Home | FAQ | Services | Articles | Software & Documentation | Contact |
|
|
||||||
|
"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:
Some example borderline languages are:
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.
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:
Figure "Algae"
image-files: [Erythrotrichia.png avrainvillea.png gracilaria.jpg padina.jpg]
image-alias: [A B C D]
output-resolution: 600dpi
output-colors: rgb
overall-width: 4in
overall-height: 5in
output-format: postscript
process: normalize-backgrounds, resample
preserve: scales
image-spacing: .1in
group: images gracilaria.jpg padina.jpg
constraints: A.left=FIG.left, B.right=FIG.right, C.top=FIG.top, D.top=FIG.top
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.
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.
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.
| ||||||