This writeup was inspired by the world's most flexible programming language. Basically, what fully-functional Turing machine equivalent language has the most specific application? Meaning that, even though the language is technically able to accomplish any programming task, it's best used for one purpose and would be terribly cumbersome and reasonably stupid to do anything else with it.

My vote is inform. Its only purpose is to create interactive fiction. Infocom forever!

Any others?

Logo is another great contestant for the goal. You're going to have a hard time with it unless you want to draw polygons. Of course, in C++ you have a hard time with everything, so it's hard to say. I'd have to vote for Klik & Play, though. Even if you can improvise a Turing complete system in it, everything is still hideously hard, as system bugs and limitations just fall over every path you find. Since all KNP can do without a great deal of hacking and slashing is a Breakout game, it's probably the most specific language ever.

TeX wins "World's Most Narrowly Useful Programming Language" hands-down. Macro languages enjoyed some popularity in the 1970s (think macro assemblers, M4, TRAC, and others). They've dropped out of most common use. The most common today of my examples is probably M4, which gets used in Sendmail configuration files and in GNU's autoconf system. Not exactly widespread use.

The C programming language's "cpp" preprocessor isn't really Turing complete, so while used it cannot count as a programming language.

Except that one macro language enjoys a large user base, new applications, and wide use: Donald E. Knuth's TeX. Knuth recognised that the chief failing of macro languages -- that anything not classified as a command gets silently ignored (so there aren't enough diagnostics for common programming) -- is an advantage when setting text. After all, in a paper most of the text is plain and not marked up. By "stealing" an uncommon character (the backslash \) as a command prefix, the macro processor is able to report many errors. For programming, all those backslashes are annoying, but for marking text they're just what the doctor ordered.

TeX is, of course, Turing complete. There's even a toy implementation of BASIC in TeX. The most common use of TeX is through LaTeX, an entire typesetting application written in TeX! There are many packages which extend LaTeX, too.

Despite all this, TeX never gets used for anything except typesetting. It's a complete programming language, big applications have been implemented with it, and it's only ever used in the one role. One of the world's most useful programming languages, and certainly one of the world's most narrowly useful programming languages!

Two other extremely narrow languages belong to the games Starcraft and Half-Life.

Starcraft boasts a level editor with a fairly sophisticated trigger system. When you make a map in Starcraft, you can create triggers, each of which consist of one or more conditions and one or more actions. Another aspect of this are locations, which are essentially boxes on the terrain which have a name assigned to them. Also included are switches, which are basically boolean variables. With some clever triggerwork, you can create AND, OR, and NOT gates, which would allow you to create almost any type of program you'd like. The main purpose of this "language" is to make Starcraft levels, though it may be possible to make something more complex with a little work.

Half-Life also boasts a trigger system. Half-Life is loosely based on the Quake engine (not, as a sidenote, the Quake 2 engine). There are three types of objects the mapper deals with: brushes, the 3D bricks that make up the physical boundries of the level; point entities, which include weapons, monsters, and many of the things that make the third type tick; and brush entities, also called models, which are essentially brushes that do things.

Half-Life's trigger system works like this: suppose you have a door and a button. They would both be models, one a func_door, the other a func_button. Entities, of both types, have whole slew of attributes, the two most important of which are "target" and "targetname." The targetname of an entity is its name, the target is its target. When an entity is triggered (say, when you push the button) it triggers its target by identifying it through the target's targetname. Clear? If not, go find a good Quake-engine mapping site. I recommend the Valve-ERC.

The practical upshot of all this is that, like the Starcraft system, you can, with a little work, make AND, OR, and NOT gates. Actually, the OR gate is somewhat built in (if any object triggers another object, it gets triggered), and the multisource entity is an AND gate for the trigger, while the multimanager is an AND gate for the target. If that wasn't clear, then I don't blame you. If you do ever start mapping for a Quake-engine-based game, then this should become clear.

It's not that these are without their drawbacks. The Starcraft engine doesn't have the concept of a variable, and the Half-Life/Quake engine can only do variables to a small degree. There are certainly ways to jury-rig a solution, but it would probably be extremely time-consuming. I'm also doubtless missing many other games, but these are the two I'm familiar with.

It would be interesting to see someone create, say, a calculator in Starcraft, though it may well be impossible.

Log in or register to write something here or to contact authors.