Ruby and the Interpreter Pattern

I think that what I liked the most about this article was the perspective it gave to us about a notation (symbolic expressions) such as the one used in languages like Lisp, since I have always considered it to be not as simple as I would like to. However, the introduction is enough to simplify and explain this structure in a way it does not look as hard as I am used to. The other thing that I like the most is the cleverness of using Ruby.

Although the language was presented to me just a couple months ago, I have grown some respect towards Ruby because how simple and yet how powerful it is. I consider it still a little hard to grasp all the things you are able to easily implement due to the tools this language offers such as the duck typing that I have found lots of times quite confusing.

Naturally this tools that I mentioned come in handy when we are presented with an interpreter pattern where there are nodes and each one represents an element of the code we are analyzing; in the end these nodes end up building a tree that is used to represent the whole program. It had come to my mind just a month ago or so, while reading for Software Design and architecture some design patterns (mainly the interpreter pattern) that using ruby to build interpreters would bring a lot of advantages, such as built in regular expressions, garbage collection, built-in hashes and open classes. 

A particular thing that caught my attention at this point and I think that is one of the most useful concepts, is that everything is treated like an object, strings, numbers, arrays, hashes, symbols, procedures and even classes.

Overall, I think that the professor's approach to teach the S-expression notation and make it a bit challenging by incorporating Ruby to the mixture, is what in the end made the whole topic so understandable, since you do not feel like cheating because of how easy it is to implement but it is not unintelligible.