Wednesday, October 21, 2009

Multi-linugal Programming Language

A fellow recently raised the notion of multi-lingual programming languages.

I have a few thoughts on the matter:

It seems to me like Multi-Lingual Programming Languages (MLPLs for short) would be an unnecessary layer of complexity, and they could make communication between international teams much more difficult. Imagine if an English speaker opened the source file from a team in India in order to isolate a critical bug and found that it was all in Hindi. Perhaps it's inconvenient for the Indians that they have to read programs in English, but at least it's a single language, not several.

Not to say that MLPLs would be necessarily be a bad thing. One thing I can imagine working would be Multi-Lingualism being supported in an IDE, or at a 'meta symbolic' (for lack of a better term) level.

For example, if we simply implemented a strict transliteration system, so that there was a one-to-one correspondence between a program written in English and the same one written in Chinese, then an editor could convert between them on the fly. This would be useful for switching between alphabets and making code easier to read for different people but doesn't necessarily carry meaning through. (The English word "while," spelled with Chinese characters is still the English word "while.")

Working with an IDE that maintains a one-to-one mapping internally between English keywords in a given language and there non-English equivalents, one could conceivably code in Russian and have the IDE internally translate it to English before passing the code to the compiler or interpreter, a sort of pre-compilation stage if you will. It could work in reverse as well, so that the canonical version is always in English (or whatever the native language of the programming language is) but coders in different nationalities see their own language.

With languages that use symbols, like Lisp, one could create a many-to-one mapping such that a single symbol has multiple printed representations depending on the (human) language in use. This would have to be enabled with a reader level switch. In Common Lisp, you could do something similar to this by creating a package for the language of your choice which maps symbols to their standard equivalents.

Non of these solutions are perfect however. For example, non handle languages designed to imitate English grammar such as SQL, for example. And they introduce complexity that may be unnecessary.

No comments:

Post a Comment