Choice 1: TMTOWTDI

The first possibility for implementing this project is to write my own language with very flexible syntax, so multiple ways of writing the same thing would be valid.

Example: FizzBuzz

    1.

    for numbers in range 1-100
        if number is divisible by 3 print Fizz
        if number is divisible by 5 print Buzz
        if number is divisible by 3 and 5 print FizzBuzz
        else print number

    2.

    for each number 0 < i < 101 {
        if (i % 3 == 0) {
            print "Fizz"
        }
        if (i % 5 == 0) {
            print "Buzz
        }
        if (i % 3 == 0 and i % 5 == 0) {
            print "FizzBuzz"
        }
        else {
            print i
        }
    }

    3.

    while i < 101
       if 15 divides i puts FizzBuzz
       elseif 5 divides i puts Buzz
       elseif 3 divides i puts Fizz
       else puts i

    4.
 
    while i < 101
    switch
       case !mod 3 and !mod 5, print FizzBuzz
       case !mod3, print Fizz
       case mod3 and !mod5, print Buzz
       else print i

So you could potentially have punctuation, like parenthesis, curly braces, arithmetic symbols, semicolons. Or not! Symbols could be written out instead of being used (% vs mod). There are multiple ways to word things (puts vs print; if/else vs switch/case). Whitespace is is optional; you could indent or not, newlines or not.

I'm feeling overwhelmed with just these few permutations! I think if I took this approach I'd have to start out small... and if I keep up with the project after my independent study I could maybe crowd-source the translator to add more possibilities. (OSS, anyone?)


PROS:

• Closest to my original idea

CONS:

• More possibilities for syntax may mean code that's harder to read (although pseudocode is supposed to be easy to understand)
• More work for me -- not only in defining the various possible syntaxes, but also writing a verbose compiler
• All the possibilities also mean that I'll have to focus my efforts, which can be difficult

CONCLUSION:

• This is beginning to sound like a terrible idea... =/
• I'll research more into the specifics of how to implement a language like this if I end up picking this path (not likely)