Introduction

This last week, for FlatIron School, Cris Hanks and I published an esoteric programming language called Precious that is in the form of a Ruby Gem. Precious uses LOTR keywords that can be translated to Ruby code. Check out the source code here: My_Precious

The Gem Pros

Turning this project into a Gem was quite possibly the best decision we could have made. As a stand alone project it was interesting. But changing the scaffolding of the project from a script allowed us to explore a new territory. Before this project I never thought to create my own Gem. Since its been released, I have really taken pride in the the work we have done. Having something that people can actively go look at, play with and contribute to is very inspiring. On top of that watching the download numbers increase is super exciting.

Cons:

When we first tried to change our project into a Gem I just went for it. I didn't do a lot of research beforehand and ran into a lot of trouble. I wasted hour of time, obliterated a branch of code and had to ask for help to go back and restore to a previous save point. In doing that I lost some commits that ended up being important. So if I could give any advice i'd say plan ahead! When you build your Gem start off in the separate root directory! I plan my next blog to be a STEP-by-STEP How to build a Gem since I made so many mistakes myself I can use them to help others.

It was/is a learning experience. When we tried to test the code in the directory we couldn't figure out how to see if it was working on not. Basically. How do you test a Gem INSIDE a GEM. gemsception The only thing we could think of was to release the code. Pushing the code live before it is ready made me really anxious. First impressions are everything so having code with areas that are not up to my standards for others to judge and see is kind of driving me insane. I kept bugging my partner about fixing bugs, wording and the README files to get them as close to perfection as I can. If I could go back again, I would figure out how to test the gem BEFORE releasing it!

The Parser

the code is BIG, repetitive and messy. I am very happy with the amount of refactoring we have done so far but I do see lots of room for improvement. Below is an example of an area I would really like to refactor.

    #check if there are strings in line
    quote = ""
    if line.include? '"'
      quote = get_quote(line)
      line = line.gsub(quote, 'quote_placeholder')
    end

    #check if line is a comment
    comment = ""
    if COMMENT_KEYWORDS.any? { |word| line.include?(word) }
      line = parse(line, COMMENT_KEYWORDS)
      comment = store_important(line, '#')
      line = line.gsub(comment, 'comment_placeholder')
    end

    #check if line has params
    params = ""
    if ((PARAM_KEYWORDS.any? { |word| line.include?(word) }) &&
      ((FUNCTION_DEF_KEYWORDS.any? { |word| line.include?(word) }) ||
      (FUNCTION_CALL_KEYWORDS.any? { |word| line.include?(word) })))
      line = parse(line, PARAM_KEYWORDS)
      params = remove_newline(store_important(line, '('))
      line = line.gsub(params, 'param_placeholder ')  + ')'
    end

    class_word = ""
    if CLASS_KEYWORDS.any? { |word| line.include?(word) }
      line = parse(line, CLASS_KEYWORDS)
      class_word = store_important(line, ':')
      line = line.gsub(class_word, ' class_word_placeholder')
    end

I also think that at this point I consider our parsing to be done "the easy" way. We basically check if a "line" AKA a string has keywords AKA another string inside it. I would absolutely rather be doing this through REGEX expression matching. For example, we really wanted to have the ability to type:

If Gollum is as smart as Smeagle
    gandalf says "fly, you fools!"
you shall not pass

HOWEVER, having 'as' and 'is' both as keywords gave us a lot of trouble. The line would translate to:

if gollum === smeagle
    puts "fly, you fools!"
end

And the === does not work for Ruby :(

Other functionality I intend on working on in the future is implementing is instead of reading in a file line by line I would like the Parser to look for end of sentence markers such as "!,.;?" That way code could be written in a paragraph form instead of line by line. I feel that this parsing works well with our design because it is based off of english and is meant to be read like a story almost.

MOST OF ALL - fix the current method definition bug

LONG TERM GOALS:

• object oriented capabilities
• Having precious EVALUATED instead of translated

Basically what I'm trying to say is, although the project is over... I plan to keep working on it for a long time!