Writing a Programming Language 101

Writing your own programming language is incredibly daunting. But if you start by writing a language that evaluates very simple functions it opens your mind to the possibility of writing an entire language and gives you a better understanding of what that would entail. So let’s start there. Let’s write a programming language that adds and multiplies numbers.

What’s in a Programming Language?

1. Parsers: Functions that read input and then tell the program what to do with it
2. Data Structure: The parser puts our input into an abstract syntax which our program can then evaluate
3. Nodes: Each node on the tree represents a value or expression which can then be evaluated to give us a value
Continue reading

Polymorphism in Ruby

Polymorphism comes form the greek words ‘polys’ meaning much or many and ‘morphe’ meaning form or shape. In programming, it refers to the ability to use functions or methods in different ways for different objects or data types.

Having the ability to use the same method in a different way depending on data input is very useful in Ruby. It greatly decreases the need for long, ugly if statements like this: Continue reading

How to Test Ruby IO

Receiving input from a user, doing something with that input, and then displaying some output is core to software development. This input and output is reffered to as IO.

In TDD, we should test the behavior of all the code we write, but testing IO can be challenging because we don’t want to be prompted for input or have miscellaneous text printed in the terminal while running our tests. I’m going to walk through a scenario where we have a UI class (i.e., user interface) in Ruby that handles all of the IO and explain how to test it. We’re also going to look at the IO class and its STDIN and STDOUT constants. Continue reading

Self & Metaclasses in Ruby

Self has confused me for a while now so I decided to get to the bottom of the purpose and meaning of self.

TLDR:

  • At any point in your program, there is one and only one self
  • Self is the current object accesible to you
  • It can also be said that Self is the receiver object of the current method (ex: String is the object in String.send(:”length”))
  • Since objects in Ruby are usually instances of classes, self is usually the class you are in at any moment
  • Using self enables you to call a method on a class (like Person), instead of just one instance of a class (like Laura)
  • There are a couple different ways to call methods on self: ‘self.some_method’ OR ‘class << self’ before a group of methods
  • You might want to use self if you want to call a method on any potential instance of that object (every Person is born on planet earth but not every Person is named Laura), especially if you don’t plan on having more than one instance of an object (maybe you’re creating a game with one Person, one Fish, and one Monkey–I’m not sure why you would do that–and you don’t want to create multiple instances of Person).

Okay, now for the longer explanation. Continue reading

Single Responsibility Principle

There’s a group of guidelines and principles to help us write clean code in object-oriented programming–commonly called SOLID–which was introduced by Robert Martin (aka Uncle Bob).

The five principles of SOLID are:

  1. Single Responsibility Principle
  2. Open-Closed Principle
  3. Liskov Substitution Principle
  4. Interface Segregation Principle
  5. Dependency Inversion Principle

Right now I’m going to explain the Single Responsibility Principle with a real world example. Continue reading

Not sure where to start? Start simple with TDD.

I’m new to Ruby and to Test Driven Development (TDD). Good thing the latter is helping me learn the former and write better code in the process.

I recently went through the Roman Numeral Kata shown by Jim Weirich here to get more acquainted with TDD. This kata showed me that through TDD I could write pretty, complex (hey, for me this is complex) code without much difficulty. Continue reading