I am not the first person to come up with the idea of a toki pona programming language. Part of my literature review is focused on looking at other implementations of this idea. Here’s a rundown of a few that I found on Github and the esolangs wiki:

“toki pi ilo nanpa” (lit. “language of number tool”) is a programming language that attempts to structure itself in such a way that all instructions are valid sentences in toki pona. The functionality of the language is based on Lua, and as a result it is fairly versatile, with a wide range of reserved keywords, and is not too much more verbose than a regular programming language. However, this brings into question the advantage of using toki pona in the first place, since this is effectively a transliteration of a standard programming language to use different keywords, and with additional rules added on top.

“toki pona li pona” (lit. “toki pona is good”) is a far more minimalist programming language that operates on a single queue-stack, similar to more famous esoteric programming languages like Brainf**k. This reduces the number of reserved symbols but makes it very verbose and difficult to express complex programs, which perhaps makes it similar in spirit to toki pona itself. However, it is a pain to program.

“toki pi ilo sona” (lit. “language of thinking tool”) takes a novel approach by abandoning the Latin alphabet and instead using sitelen pona, a system of hieroglyphics where each glyph represents a word in toki pona. This is an interesting approach as programs written in this language are graphically quite short, similar to other programming languages making use of non-alphabetic written languages, while still having the versatility of a traditional programming language. The main issue is that no major operating system supports the display of sitelen pona characters, and most people do not have a keyboard that can type them, meaning the language is not very portable. Keeping implementations to the Latin character set may be more practical.

Knowing and being able to criticise these approaches that have already been taken will allow me to evaluate how I want to approach the problem myself. Currently, I am leaning towards an approach that avoids the use of any symbols, but I will probably not enforce grammatical correctness to the same extent as other approaches so as not to stifle the language or make it more “ike” (complex/bad).