A World Without IP

Day 1: John invents new computing material that highly outperforms silicon and is cheaper to make as well. Having just finished watching The Wrath of Khan, and because of its remarkable similarities to siliconn, John has named his invention Silly Khan.

QUANTUM WORLD SPLIT

World 1, Day 5: John freely releases the designs and procedures for constructing this new material. Richard Stallman hails this support of open source. He also accepts a high paying job from a company to help train in making the material and selling it, and he is invited to conferences to discuss his work and its advantages. All of this is breaking news everywhere.

See Full Post and Comments

Introductory Object Oriented Programming

This is meant for a beginning student of any programming language that has a concept of functions and variables. If you can understand the following pseudo-code (which is fairly math-influenced):

f(x) = x*x

let a = f(3)

let b = a + 1 // b is now 10.

or even if you just have the basic notion of functions and variables in your head, you're ready to read this. (A brief refresher anyway: in general, functions are data structures which receive input and return output. Variables can be set up to receive the values of the input and output.)

What is Object Oriented Programming (OOP) all about, anyway, and why is it useful? On a very abstract level, it's about the Real World and makes programming seem more similar to things you do in every-day life. It's useful for that specific reason. OOP is intuitive, it mimics how things really are to us. On a slightly less abstract level, OOP is about multiple, independent, and 'intelligent' agents. Let's go over these terms using real-world objects.

In my left hand, I hold an apple. In my right hand, I hold another apple. There are two apples, therefore there are multiple apples. Are they the same apple? If that were true, then I would expect that after I took a bite out of my left apple, a bite would magically be taken out of the right apple as well. This is not true, however, so we say the apples are independent.

What's an intelligent agent? It's anything we can personify mind-like attributes to. Let's pretend our apples have brains and a mouth--I can ask the one on my left "What color are you?" and it might reply "Why, I'm red of course!" I could ask the same question to the apple on my right, and it might reply "Why, I'm green of course!" I have personified the apples in such a way that they behave like people; I can ask them questions, and depending on how smart they are, they can answer my questions. (I think it would be overestimating the intelligence of an apple to ask it to solve for x in a right triangle.)

So, OOP is about "multiple, independent, and intelligent agents". It's useful because it mimics how we like to think about the real world. Of course we know apples can't talk, but wouldn't it be so useful if they could? It would be so useful if I could just ask an apple seed "What kind of apple will you grow up to be?" It is this usefulness that we wish was reality which OOP captures.

The question of "What is an Object?" should be slightly clearer by now. An Object is an independent intelligent agent. If this is not clear yet, please go back and reread until it is.

Now it is time to get a little less abstract as we try to further define the essence of an Object. We know what we want on the high level (multiple independent intelligent agents), but how might we do this with a computer that works with functions and variables? What is it these Objects are supposed to be able to do? There are three key terms: message passing, local state, and inheritance. Let's again define these terms.

Message passing is what it says. If I have an apple Object, I can send it a message in the form of a question: "What color are you?" However (and this will be important soon), I don't speak fluent AppleSpeak, so it would be wise of me to pass this message to a translator who will ask the apple Object on my behalf. The verb "passing" is key, here. If I'm talking to the apple, either directly or indirectly, I'm really just sending it messages. But because I don't speak AppleSpeak, I need my message passed along through something that does.

Local state is a fancy way of saying independent. Why repeat it? Well, we're at a slightly lower level of abstraction remember. Local state pertains to everything you can say about some apple Object. Its color is some fact about it, and I might change that color by dipping it in dirty oil, but I should expect that action to not change any other apple Objects I might have with me. To make the point clearer, perhaps, let's take a brief dip into an even lower-level of abstraction. An apple's "color" is a variable specific to that apple alone. If I modify it, I can expect the state (value) of that variable to be local (with respect to this apple Object) only.

Inheritance is one of the most powerful ideas about OOP, and indeed nature. Consider yourself: you had exactly two parents, and your genes are a mixture of the two, but you share very similar attributes with your parents. If both of your parents have brown eyes, chances are you also have brown eyes. If both your parents have the emotion "happiness", chances are you also have the emotion "happiness". Humans are very complex creatures, and it would be horribly inefficient and error-prone if parents had to explicitly state every single attribute they wanted their children to have. It's far easier to say "Be just like me, except 2 inches shorter and a little smarter" compared to "I want you to have this, this, this, this, ..., and this" and finding out you forgot to give your child empathy.

This is the concept of inheritance. Just as you inherited many attributes from your parents, thus an Object can inherit many attributes from its parent(s). Note the parenthetical 's': in programming, we're not limited by biology to having exactly two parents. We may have one, or ten. We may also have zero or more grandparents, and we may have zero or more children. OOP is more flexible than reality in this way.

What is an Object, and what does it support? An Object is an independent intelligent agent, and it supports message passing, local states, and inheritance. If this is not obvious to you, please reread above before continuing, as we're about to jump yet another level down the tower of abstraction.

We're down at the level of actual code now. How is this supposed to work? What must our programming language support for us to do OOP? Again there are just three components; these are functions which encapsulate the above ideas into a structured syntax. The functions are: define_class(), instantiate(), and ask().

There is some new terminology here. What is this "class", and what does the verb "instantiate" mean? A class can be equated to a template for your Objects. It is the blueprint. If I'm an architect and I want to build a couple of identical buildings, I don't rewrite the blueprint for each one, I just use the single blueprint. The blueprint for the building is the Building Class, and each actual building I construct is a building Object. The template might define things like how many windows there are, or a way to add and remove stories to the building. This gives us some flexibility with the Objects. If I make a building in New York from these blueprints, it might be 200 stories high and have 2,000 windows. But I might also make a building in Seattle, using the same blueprints, but now the only difference from the one in New York is that this building has 50 stories and 500 windows.

The verb "instantiate" means "to create an instance of." In the context of OOP, we're creating instances of classes. In order to create a building, I must create a building Object. Because each Object is independent and there may be multiple ones, I can't just equate it with the blueprints of the class: I must instantiate it out of the class.

If the concepts of what it means to create a class and what it means to create an Object of that class by creating an instance of that class are not clear, then again, please reread until it is. If you're good to go, put on your programming caps, since now we're going to technically discuss the three functions.

define_class() creates a class, or a template, to use in your code, and it behaves like a function itself. For simplicity's sake, we'll say it only takes one argument: the class name. An apple class might look like this:

define_class(apple) {

  color = "red";

  

  method(what_color?) {

    return "I am the color: " + color;

  }

}

This pseudo-code probably doesn't match what you've seen in your language if you have prior OOP experience; that's okay, I'm going to explain it. Do you see what define_class() is doing? Its argument is a word which is the class name. Inside of the curly braces is the class implementation, or the actual substance of the blueprints. Inside we have a local variable named color, set to a value of red in quotes, and something called a method. A method is a special type of function that exists only within a class or Object; the method() function works like define_class() in that its argument is the method name, and inside its curly braces is the implementation of it. Methods are the brains of your Object. In order to ask an apple what color it is, the apple must have a method to process that question. If you want to ask more questions, add more methods.

Once the above code is run, we now have an apple class to work with. Let's make some objects.

instantiate() creates an instance of a class and returns an Object. It takes one argument: the class name. So some pseudo-code for that is this:

left_apple = instantiate(apple);

right_apple = instantiate(apple);

We now have two apple Objects: one on the left and one on the right. These objects are separate from each other, but they are both apples and both behave like apples. Let's ask them a question.

ask() sends a message to a given Object, and returns whatever the Object responds with. It takes two arguments: the object, and the message. You as a programmer pass a message to this function, which does the sending--remember, you don't speak AppleSpeak. Let's check this out:

left_color = ask(left_apple, "what_color?");

print(left_color);

This pseudo-code will display to the screen the words "I am the color: red". Notice how our message is in quotes? That's our English. The ask() function takes our English and converts it to AppleSpeak, asks the apple Object the question now, takes the response, converts it back to English, and returns it into our left_color variable.

That's all there is to OOP in a nutshell. If you want to do inheritance, use a function called parent() inside the class definition to specify. (Unfortunately, useful examples of inheritance are typically complicated. See below for a semi-useful one, though.) If you know the apple class has a variable called 'color' in it, you can just ask for that variable directly with ask(apple_object, "color").

As a beginner to OOP, you're done with this tutorial, and you're ready to learn the actual syntax of your language of choice to do all this, along with things that are not immediately obvious from this. As a benefit for more advanced readers, however, the following short section goes over a few other things you might have heard about OOP, and how the syntax defers in the pseudo-code from a language like Java. If you're just beginning then again, you're done, and thank you for reading this.


First of all, here's an example of inheritance:

define_class(EnemyCharacter) {

  health = 20;

  attack_power = 30;



  method(attack) {

    return "I attack with power " + attack_power;

  }

}



define_class(Tank) {

  parent(EnemyCharacter);

  health = 40;

}

The first class is a generic EnemyCharacter template. Enemy characters all have health, all have attack power, and they all have the ability to attack. I could make a generic enemy Object that is instantiated from the EnemyCharacter class, and I could say: ask(enemy, "attack") to ask it to attack, and it will respond with a message indicating its attack power.

The power of inheritance is that I can make a tank Object from the Tank class, and because its parent is the EnemyCharacter it shares all attributes with the EnemyCharacter class. If I want to change something, I do it after calling parent(). In this case, the only thing different is a higher health. Now even though I didn't specify the method "attack" anywhere in the Tank's class definition, it still knows what an attack is thanks to its parent. Thus I can ask(tank, "attack") and it will respond just like an enemy would. This is the power, but I apologize I can't give a more thorough example. Look at actual source code for large projects for (potentially) good examples.

In other classes you might have heard that OOP is about these three things: encapsulation, inheritance, and polymorphism (there is sometimes even a fourth thing called composition added on later). Encapsulation is the same idea as local state, and polymorphism and inheritance go hand-in-hand so it's simpler to just refer to inheritance. This concept of message passing is key, I think, and it's too often skipped over. Message passing is at the heart of all OOP. In Java, an apple class and object would look totally different from the above pseudo-code, but the concepts are all there.

// apples.java

public class apples {

  public static void main(String args[]) {

    Apple left_apple = new Apple();

    Apple right_apple = new Apple();

    

    String left_color = left_apple.what_color();

    String explicit_left_color = left_apple.color;



    System.out.println(left_color);

    System.out.println(explicit_left_color);

  }

}



class Apple {

  public String color;



  public Apple() {

    color = "red";

  }



  public String what_color() {

    return "I am the color: " + color;

  }

}

So much uglier... Anyway. The define_class() function is abstracted into the "class" keyword. If you want to have inheritance, then you use the keyword "extends". (Java unfortunately doesn't support multiple inheritance.) The instantiate() function is abstracted into the keyword "new". The ask() function isn't so obvious, though--it's the dot operator. object.method() is the same as ask(object, "method").

As you see, most OOP languages nowadays hide the actual functional nature of OOP by using keywords. But I think knowing this functional nature is very important to understanding what OOP actually is, and if you're further advanced, how you might implement it from a language that doesn't natively support OOP via keywords.

[This post is released of all no-derivative rights. Meaning you can use it in its entirety or in parts or to create your own reference with no restrictions.]

See Full Post and Comments

Classroom Opinion Polls

After having yet another one of these awkward experiences yet again, I've decided classroom polls aren't very useful and perhaps sometimes dangerous.

In school the other day, the teacher asked "How many of you don't want your parents on Facebook?", meaning they don't want their parents to see their profile for whatever reason. I misheard this: "How many of you don't have parents on Facebook?" and so I raised my hand. It wasn't until maybe 5 minutes later after the discussion had moved on that someone mentioned something related to hiding identities from parents and it clicked what the question really was.

I thought: "No, no! I didn't want to vote for that! I've been completely misrepresented, and since it was a public poll everyone saw." But there was no way to express that; the vote was long gone, we were on a different subject now. My only solace is the observation that students don't pay much attention to class polls.

See Full Post and Comments

I can't do this alone!

So it has happened, Tom mused. The majority have finally voted for Anarchy, and the government will start phasing out of people's lives. Tom took another swig of his beer and scowled. Another man at the bar looked at him--a man with glasses, nice looking clothes, and a simple Pepsi in front of him. Tom noticed the other's gaze and, wondering why such a man was in this old bar, he muttered: "No more government."

"You like the government?" the other man asked sharply.

"Well.. Sort of."

See Full Post and Comments

Vim and [language] Interpreter

I've seen emac's lisp mode, and I'll admit it made me somewhat jealous since it wasn't as easy (and at first glance seemed impossible) to do in vim. But I've learned a few more neat tools, and now combining vim with a bunch of other *nix utils results in an awesome split-screen window with vim and any language interpreter you like. This is one reason I like vim: it doesn't try to be everything. You use other tools to enhance it, sure, but it doesn't include them by default.

What you'll need (you should be able to get these from your Linux distro's package manager):

vim (compiled with xterm support, Gentoo USE flag is vim-with-x)
screen
xsel

See Full Post and Comments

Learning the Deep Magic

Followup to: Programming is the closest thing to magic

Well, classes are starting next week at DigiPen. I'm a freshman this year, finally out on my own from high school. There are around 120 people in my freshman class, which is awesome, and I'm getting to know some people.

What degree did I choose? Computer Engineering. "But that's a school to teach you video game programming! Why didn't you go to MIT or some other fancy school renowned for engineering?" Well, I was asking myself a similar question a few days ago. I knew I answered it several months ago when I initially applied, but I forgot the answer. So I've re-derived it and I'm posting it here so I don't forget.

See Full Post and Comments

On Altruism

Altruism:

1 : unselfish regard for or devotion to the welfare of others
2 : behavior by an animal that is not beneficial to or may be harmful to itself but that benefits others of its species
- Merriam-Webster Dictionary

and

See Full Post and Comments