Wiki
Bliki

Not So General Purpose Language

The concept of a general purpose language is a falicy. All languages are designed with a certain range of specific tasks in mind. Some languages turn out to be more flexible than the language designer intended, but all languages in the end are still only truly suitable for a limited number of tasks.

Most languages are Turing Complete and designed to run on a machine that is equivalent to a Universal Turing Machine. However being Turing Complete is not the same as being general purpose. Characteristics such as efficiency, speed, brevity, clarity, simplicity and expressiveness do not affect a language’s qualification for Turing Completeness. It is these characteritics that determine whether a language is suitable for a certain task.

A lot of the bad code that exists in the industry and academia today is due to the fact that the programmer is attempting to use the language for a task that it was not designed for.

As mentioned in previous posts, the closer the match is between the language and the requirements, the greater the chance that the software will be high quality. So what should be done when there is a certain task that does not have an existing closely matched language? In most cases, 2 routes have been taken:

1. Use a less suitable language and attempt to write software that bridges the gap. This software tends be poor quality, bug ridden and costly. These penalities multiply each time the requirement change.
2. Design a new language and write a compiler/interpreter for it. The software written in the new language tends to be higher quality and incur far less penalities when the requirements change. However it shifts the possibility of poor code, bugs and costs to the language designer and compiler/interpreter writer.

There is a 3rd option, where a new language is designed and implemented on top of an existing base language. This provides the best of both worlds described in the 2 previous options : a suitable language for the task, but most of the penalities have already been paid by the base langugage, which is hopefully mature. This is also the least commonly used option, mostly because are very few base languages capable of supporting an embedded language. The Lisp family of languages are the most suitable to achieving this 3rd option. Ruby is also capable, although to a lesser extent. Even these 2 languages still aren’t suitable for many tasks, as these base languages are high level and are not capable of embedding a low level language.

The final option that has not been explored by anybody is to design and implement a low level meta language. This can then be used to embed either a low level target language or embed a higher level meta language (which is essentially what Lisp is) and from there finally embed the target domain specific language.