I just posted a short screencast on how to get started with Clojure and Aquamacs:
One of the fun features of Clojure, or any Lisp I suppose, is the interactive development workflow. As you can see in the video, you write code by creating expressions that define functions and then you evaluate those functions in the REPL (Read-Eval-Print-Loop). You can redefine a function at any time. You can imagine that if you had a production system running, you could connect to it via a REPL or something like that, evaluate some expressions that redefine functions that contain bugs, and the system would be fixed with no downtime.
Here's the contents of the ~/bin/clj script:
#!/bin/bash
SRC_DIR=/Users/pbarry/src
CLOJURE_JAR=$SRC_DIR/clojure/clojure.jar
JLINE_JAR=$SRC_DIR/jline/jline-0.9.94.jar
if [ -z "$1" ]; then
java -cp $JLINE_JAR:$CLOJURE_JAR jline.ConsoleRunner clojure.lang.Repl
else
java -cp $CLOJURE_JAR clojure.lang.Script $1
fi
Today I was working on a Rails site where users have profiles that anyone can view, but if you are viewing your own profile, there are links on the page to edit various parts of the profile. I want the links to show up if you are viewing your own profile, but not be there if you are viewing someone else's profile. To implement this is trivial, as any Rails developer would tell you. I simply added a helper method:
def link_to_if_owner(title,url,options={})
if current_user == @user
link_to title, url, options
end
end
And changed the occurrences of <%= link_to "Edit", edit_something_path %> to <%= link_to_if_owner "Edit", edit_something_path %>. This probably took 15 seconds, and could not be more clear and succinct. When I compare this to doing Java/J2EE development, this task would probably have involved a custom JSP tag and would have been a complicated solution with much ceremony.
This is what is referred to as the means of abstraction in SICP. They assert that the power of a programming language or framework should be measured by its means of abstraction. The means of abstraction is how you take a set of operations and build a smaller operation that you can build on top of. This is just one example of many that shows why Ruby/Rails is a more powerful combination than Java/J2EE.
Every object in Ruby is an instance of a class. Each object knows which class it is an instance of (which I will refer to as a class pointer), keeps track of some basic properties like is it frozen, it is tainted, is it a virtual class, etc. and has is a table of instance variables. What objects don't have is methods.
Classes are very similar to objects. In fact, in Ruby, classes are objects. (Note that this may or may not be the case in the internals of the interpreter, and is not the case in MRI, but it doesn't matter as far as this discuss goes). In Ruby, classes are instances of the class Class. Once you understand this, many things in Ruby like def self.foo or class << self really start to make sense.
Because classes are objects, they have the class pointer, the same basic properties as all other objects and also have a table of their instance variables. But in addition, a class has a super pointer, which points as the parent class of the class and a method table, which is where all methods for a class are stored.
So when you send a message to an object (a.k.a call a method on an object), Ruby first looks at the class pointer of the object. It figures out which class it is pointing at. Then it looks in the method table for that class. If it has a method, it calls that method. If there is no method in the method table, it uses the super pointer of the class to find its parent class. It checks the parent class's method table and keeps doing that until it finds a method or gets to a class that has no parent. And that's it. One of the "rules" of Ruby is that this is the process for looking up a method, which is known as method dispatching, in all cases in Ruby. There is only way of doing method dispatch.
Now, you might see code like this:
class Animal; end
dog = Animal.new
cat = Animal.new
def dog.speak; puts "woof"; end
def cat.speak; puts "meow"; end
dog.speak
cat.speak
Which prints woof and then meow. In this example, dog and cat are both instances of the same class Animal, but they respond differently to the speak method. But how does Ruby achieve this instance specific behavior? Objects can't have methods, so the method must be defined on a class, but the method could not have been defined on the Animal class, otherwise one would have overwritten the other.
The answer is the singleton class. It is called the singleton class because it is a class that there can only be once instance of. Ruby wants to have instance specific behavior and wants to adhere to the rule of having just one method for method dispatch. In order to achieve that, when you define a method on an instance, Ruby creates a singleton class, makes the class pointer of the object point to the singleton class and makes the super pointer of the singleton class point to the class.
Once you have the singleton class in place, method dispatch can proceed as normal and everything works and you now have instance specific behavior. But what about this?
dog.class == cat.class
This evaluates to true. But that's can't be, because the class pointers of dog and cat are pointing at different classes, a singleton class for each object. The answer here is that the method class does not actually return the direct parent of the object. It returns the first non-virtual class in the object's inheritance chain. A singleton class is a virtual class, and there other types of virtual classes that I will mention later.
Now that you understand the concept of singleton classes, class methods should be clear. As I said earlier, every class is an instance of Class. Each instance happens to be assigned to a constant, but it doesn't have to be. We can modify our previous example like this:
animal = Class.new
dog = animal.new
cat = animal.new
def dog.speak; puts "woof"; end
def cat.speak; puts "meow"; end
dog.speak
cat.speak
puts "dog is a #{dog.class}"
This will print woof and meow as before, and the last line will print something like dog is a #<Class:0x129dd0c>. Normally the last statement would print dog is a Animal, but a class doesn't get a name assigned to it until you assign the class to a constant.
So class methods are really just instance specific behavior defined on the class object. Class methods are defined in the method table of the singleton class of the class, not in the class's own method table. There is a difference between the way the singleton class of any Ruby object is handled and the way a singleton class of a class is handled. Because of this difference, Patrick refers to the singleton class of a class as a metaclass, although there is much debate about that particular nomenclature. Ola Bini says Ruby doesn't have metaclasses at all, whereas Why The Lucky Stiff refers to all singleton classes as metaclasses. Personally, I think Patrick's definition makes the most sense and I'm going to use his definition throughout the rest of the article. Also, the metaclass of a class is notated by prefixing it with a single quote, so Dog's metaclass is 'Dog.
The difference between a metaclass and singleton class has to do with the super pointer. Let's say for example, we define a Dog class that is a child class of Animal and we put a class method on each:
class Animal
def self.foo
puts "foo"
end
end
class Dog < Animal
def self.bar
puts "bar"
end
end
puts "#{Dog.foo} #{Dog.bar}"
Both Dog and Animal are instances of Class. Their class pointers both point to each of their metaclasses, and those metaclasses class pointers point to Class (there are actually a few other things in the chain, but for the purpose of this discussion, it's enough to say that they point to Class). foo is defined in 'Animal's method table and bar is defined in 'Dog's method table. What we want and what happens is that the class methods are inherited. But that wouldn't work by the rules of method dispatch as I've already covered.
When you send the message foo to Dog, Ruby would check its class pointer, which is pointing at it's metaclass. The method table of 'Dog has no foo method. So then Ruby checks 'Dog's super pointer, which points at Class. Class's method table has no foo, so you would get a method missing error.
But that's not what happens, what does happen is that the foo method defined in 'Animal gets call. The rule that makes this happen is:
Normally when a singleton class is created for any object, the super of the singleton class points to the class of the object, but when it is a metaclass (the singleton of an object that is a class), the super gets pointed to the metaclass of the object's super. So as the fortune cookie says, "The super of your metaclass is the metaclass of your super".
One last wrinkle in method dispatching are Modules. Modules, or mixins, as they are sometimes referred to, provide a way of adding methods to a class in a way that provides the benefits of multiple inheritance without actually doing multiple inheritance.
A module is just like a class, it has a super pointer and a method table, in fact in Ruby, Class inherits from Module. When you include a module in a class, effectively what happens is that the module inserts itself in the inheritance chain of that object, much like how the singleton class works. But the problem is that in order to do that, you would have to change the module's super pointer, and since the same module can be included in difference classes, that can't work.
So the way Ruby deals with this is that when a module is included, a virtual class is created. That virtual class doesn't have a method table of it's own, instead it has a pointer to the method table in the module. This makes it so that if you have a module that is included in multiple classes, if the module is changed, all classes see that change. The virtual class's super pointer points at the next class up in the inheritance chain for the object, so now each object has a virtual class for each module it includes, and method dispatching can continue to work as it does in all other cases.
I've had a chance to play around with iPhone over the past few days. I took a couple of shots with the camera, just to see how the quality is. It's much better than the quality of photos you get with a typical phone. See for yourself:
The other cool thing is that it stores the exact location that you were at when you took the photo. Google can read this info, so if you look at the map view, you can zoom in on the exact location.
The MLB All-Star balloting is open, but before you cast your photo, I'd like to inform you about the most important stat that you should be looking at, one that MLB doesn't show you. If you click on the compare stats link for AL second basemen, you will see something like this:
Now as much as I would love to vote for Robinson Cano, the only players you really can consider here are Jose Lopez, Dustin Pedroia and Ian Kinsler. Based on these misleading numbers alone, you may think that Ian Kinsler is the right choice, but you'd be wrong. If you check out these stats from fangraphs.com, you'll see the right choice, based on WPA, is Dustin Pedroia.
WPA stands for Win Probability Added. How it works is that you can breakdown a baseball game as a finite set of states. The game moves from one state to another, one batter at a time. For example, when the game starts, it is the Top of the 1st, 0 base runners on, 0 out, and the score is 0-0. At this point, each team has a 50-50 chance of winning the game (note that it is not actually 50-50, I'm sure the home team wins more often the road team, but it doesn't matter for the sake of this example). After the first batter, there are 5 possible states the game could be in:
Top of the 1st, runner on 1st, 0 outs, 0-0
Top of the 1st, runner on 2nd, 0 outs, 0-0
Top of the 1st, runner on 3rd, 0 outs, 0-0
Top of the 1st, 0 runners on, 0 outs, 1-0
Top of the 1st, 0 runners on, 1 out, 0-0
Notice, by the way, that it doesn't matter how the hitter gets to first base, a hit, walk, error, etc. This is why OBP (On-Base Percentage) is a much better stat than AVG (Batting Average). And also, if the batter is out, it doesn't matter if he strikes out, flies out or hits a line drive. Many people look at the number of times a batter strikeouts, as if having a lot of strikeouts is bad. Striking out isn't good, but it's not any worse than a line out or pop out. The number of strikeouts a batter has is often over-emphasized in my opinion. A guy who has a lot of homeruns, walks and strikeouts is much more valuable than a guy who has a lot of hits, but few homeruns and walks. In fact, a walk is better than a single, because a batter is likely to make a pitcher use more pitches in the process of drawing a walk, versus getting a single on the first pitch. Same goes for a strike out, you are better off striking out on a full count than popping up the first pitch.
Alright, back to how WPA works. Once the game has moved into one of the 5 states, you can recalculate each teams odds of winning. I'll use fictitious numbers to illustrate. Let's say after the first batter, the game moved into state #1 from above. Let's also say that there have been 100,000 games in the history of baseball that have been in that state. And out of those 100,000 games, the road team won 55,000 of those games and the home team won 45,000. In that case, the lead off batter increased his teams' chances by 5%, from 50-100 to 55-100. As I mentioned before, the actual numbers are different, but that's the concept.
So you can keep track of how much a batter increases/decreases his teams probability of winning with each at bat. This running tally is what you see in fan graphs in the WPA column. And as you can see from the stats for AL second basemen fangraphs.com, Dustin Pedroia has done more to increase his team's chances of winning and in fact, Ian Kinsler, despite his good numbers, has had an overall negative impact on his team's chances of winning. How does that happen? Well, it's simple if you think about it. If Kinsler hits a 3-run home run with his team up 8-0, but then the next night strikes out in the 8th inning of a game with runners on 2nd and 3rd with his team down 5-3, what's his overall impact on the team?
Announcers of baseball games inherently know this. For example, as I write this, the Jose Vidro just singled to right center, scoring Ichiro and Jose Lopez, extending Seattle's 3-2 to 5-2. Michael Kay announced it as a big base hit and it was, but Fan Graphs actually gives you a way to measure it. As you can see from the game's Live Play Log, with that hit, the Yankees' chances of winning (a.k.a Win Expectancy, or WE) went from 21.7% to 10.9%.
As you can probably tell, I love Fan Graphs. What surprises me is that major networks that cover baseball like Fox, ESPN, etc. have failed to incorporate WPA and WE into their broadcasts. I think fans would really like this. It could be displayed very similar to the way poker is covered on TV, with each teams chances of winning or losing displayed as each play happens. Instead of the score of the game being shown as NYY 5 - SEA 3, it could be NYY(66%) 5 - SEA(33%) 3. And as each batter comes to the plate, instead of displaying misleading stats like AVG, HR, and RBI, they would show AVG, HR, RBI, OBP, SLG, OPS and WPA. These additional stats give a much clearer picture of how well a given hitter is doing.
Here's an example of how misleading the traditional AVG, HR, RBI stats can be. Compare these two hitters:
Obviously Garrett Atkins is having a better season and is therefore more valuable to his team? Well what if I told you Garrett Atkins' WPA is -0.49, whereas Melvin Mora's is +0.63? Now who's having a better season?
