I apologize if I've been distant lately; right now I'm in the process of rebooting my life.

Friday will be my last day with IBM.

Over the next few weeks I'll be relocating to the Bay Area to work for Google.

If you'd like a peek at what I've been up to at work for the past eight months, head over to jazz.net, which just went live.

The details are still kinda sketchy, but expect more real soon now :)

(DON'T PANIC! I probably don't mean what you think I mean.)

On a long enough timeline, the survival rate for everyone drops to zero.

Steve Yegge has a thought-provoking essay on living systems vs. dead systems, in essence: systems that can be modified at runtime vs. systems that you have to stop (kill) first to modify.

In this context Eclipse is a "dead system" (or "hardware" as Stevey says). And this makes me sad :(

In fact, it's saddened me for a while, though I've never framed the issue in these terms.

Even though Eclipse has a world-class extension system, we have to go through an onerous process of launching and relaunching Eclipse instances to make the slightest change to a plugin.

In contrast, a "living" system like Emacs doesn't have this problem. In Emacs we can evaluate s-expression, set variables, rewrite functions, and swap code on the fly without having to relaunch - which is why writing Emacs extensions is an order of magnitude easier (and more fun) than writing Eclipse extensions.

Stevey also draws a parallel between how long a system can stay running without reboot, and how long people will continue to use the system.

*shrug*

I think it has more to do with how close your system gets to hitting the best solutions to the problems people are trying to solve on any given day. But here's the thing: the problems of today aren't necessarily the problems of tomorrow, nor the problems of ten years from now.

The more malleable your system is, the better its chance of solving the problems of 2007, and 2008, and 2017, and 2027. And as it happens, systems that can be modified without a reboot are much easier to modify and far more malleable than systems that can't.

Eclipse has many advantages over Emacs (mostly in terms of gooeyness), but as ugly as Emacs looks on the outside, it's definitely the more malleable of the two. So, if I had to choose pick which one is more likely to be around in 100 years, my money would be on Emacs. And if history is any guide, that's probably not a bad bet.

UPDATE:

Hehe, as Bill points out in the comments, I do feel like kind of a bastard for writing this post (especially the inflammatory title). But my aim isn't to disparage Eclipse. I love Eclipse. It's a great platform, and it's very good at what it does.

And no... it's certainly not "dying" :)

My aim is to point out that there are other kinds of extensibility out there that we don't typically get with Eclipse... at least not right now, and it's the kind of extensibility I'd very much like to see.

And just for full disclosure, I work for the company that originally founded the Eclipse project. All views expressed here are my own and not those of my employer.

We meet twice a month: the first and third Tuesday, 6:30PM at the Helios Coffee Company.

Details at the wiki.

Tonight will be our first meetup of the year. If you live in Raleigh or around Raleigh, please join us! I'd love to meet you in person.

(Dave even has Helios photos)

Bazaar or bzr is a Python-based source code management system that I've noticed is becoming increasingly popular amongst small open-source projects.

Right now I'm not sure what advantages bzr might have over other SCM systems such as Subversion (I suspect it's more light-weight), but it's handy to have when you want to grab the source for a project like Planet Venus.

Here's how I installed bzr on my Dreamhost shell account.

(note: There's not anything special here. This is all pretty standard Unix tarball installation fair. In fact, there's little here that isn't already in the bzr installation guide. I'm providing this as a confidence cushion for other Dreamhost users.)

Fetch it

Downloads of bzr are available here: http://bazaar-vcs.org/Download

Fetch the tarball install into a directory of your choice:

~$ cd ~/incoming
~/incoming$ wget http://bazaar-vcs.org/releases/src/bzr-0.13.tar.gz

Unzip it

~/incoming$ tar -zxvf bzr-0.13.tar.gz

Install it

~/incoming$ cd bzr-0.13
~/incoming/bzr-0.13$ python2.4 setup.py install --home ~

No problem...

Adjust environmental variables

... except one hiccup when we try to run bzr:

$ bzr
bzr: ERROR: Couldn't import bzrlib and dependencies.
Please check bzrlib is on your PYTHONPATH.

Traceback (most recent call last):
  File "/home/joshstaiger/bin/bzr", line 62, in ?
    import bzrlib
ImportError: No module named bzrlib

Because we installed bzr in our home directory, the Python code behind bzr is living in a nonstandard location that Python can't see. We add this location to our Python library path by setting the PYTHONPATH environmental variable in our .bashrc.

Modify .bashrc as follows:

echo "export PYTHONPATH=/home/joshstaiger/lib/python" >> ~/.bashrc

(replace "joshstaiger" with your shell login name)

We'll also want the bzr manual to be in our MANPATH if it isn't already, so we can read about bzr in our spare time instead of picking up women:

echo 'export MANPATH=$MANPATH:/home/joshstaiger/man' >> ~/.bashrc

Source .bashrc (or relogin) to pick up our changes:

. ~/.bashrc

Run it

~$ bzr
Bazaar -- a free distributed version-control tool
http://bazaar-vcs.org/

Basic commands:

  bzr init           makes this directory a versioned branch
  bzr branch         make a copy of another branch

  bzr add            make files or directories versioned
  bzr ignore         ignore a file or pattern
  bzr mv             move or rename a versioned file

  bzr status         summarize changes in working copy
  bzr diff           show detailed diffs

  bzr merge          pull in changes from another branch
  bzr commit         save some or all changes

  bzr log            show history of changes
  bzr check          validate storage

  bzr help init      more help on e.g. init command
  bzr help commands  list all commands
  bzr help topics    list all help topics

Ok, I was wrong.

Looks like they will be fighting us every step of the way.

*shrug*

Steve just lost my willingness to give him $599 and put my balls in a vice grip with his carrier (which I otherwise would have done gladly, just to play in the new sandbox).

I will, however, continue to write webapps that incidentally work well on his phone, safe in the knowledge they'll no longer have to be crippled to be mobile.

Tonight, every nerd I know is salivating over the iPhone.

Obviously people are orgasmic over the sexyness: the form-factor, the fluid touch-screen, the (for serious!) smart calling software, the media apps, and the internet connectivity.

But I think the real story here is we finally have a real platform for mobile application development, complete with real OS, real apis, and a real web browser capable of running real web applications - all delivered by a company that isn't going to fight us every step of the way.

And the sexyness ensures it's going to be very popular.

It almost sounds like the mobile platform we've been waiting for for the past ten years!

This is going to be big :)

In my previous post, Of Closures, methods, procs, scope, and Ruby, I discussed how blocks and procs are closures in Ruby while methods are not.

To review, this won't work:

class MyClass
    @friend

    hello_string = "Hello"

    def initialize
        @friend = "Kitty"
    end

    def say_hello
        puts hello_string + " " + @friend  # Bzzt!  hello_string is not in scope
    end
end

my_object = MyClass.new

my_object.say_hello # Bzzt!

And neither will this (at the toplevel):

hello_string = "Hello, world!"

def say_hello
    puts hello_string  # Bzzt!  hello_string is not in scope
end

say_hello # Bzzt!

In response Kurt hypothesized we could get method closures in Ruby with a bit of metaprogramming.

And he's right.

As Bryce points out, Ruby's Module class has a private method nammed define_method that defines a new method given a symbol representing its name, and a block representing its body.

Because the second parameter is a block, and blocks can be closures, this gives us the key to defining method closures.

Within the context of a class definition:

class MyClass
    @friend
    hello_string = "Hello"

    def initialize
        @friend = "Kitty"
    end

    define_method(:say_hello) { puts hello_string + " " + @friend }
end

my_object = MyClass.new  

my_object.say_hello # Hello Kitty

Yay!

But suppose we want to define one-off methods from the top-level instead.

Because define_method is private, normally we wouldn't be able to call it outside a class definition, but we can get around this using the send hack.

Let's define a convenience method:

def lexdef(method_symbol, &block) 
    self.class.send :define_method, method_symbol, &block
end

And now we can define method closures from the toplevel:

hello_string = "Hello"

lexdef :say_hello do |friend|
    puts hello_string + " " + friend
end

say_hello "Kitty" # Hello Kitty

Voilà! An unobtrusive syntax for defining method closures!

I like it :)

As of Ruby 1.8, blocks don't yet support Ruby's first-class syntax for receiving block arguments. So this won't work:

hello_string = "Hello"

lexdef :say_hello do |friend, &formalize|   # Bzzt!  Syntax error
    puts hello_string + " " + yield(friend)
end

say_hello("Kitty") { |friend| "Ms. " + friend }

But word on the street is &block arguments to blocks will be supported in Ruby 1.9.

I stumbled across an interesting Ruby hack that doesn't seem to be written down anywhere.

It turns out that private methods in Ruby aren't entirely private, and with a bit of indirection you can gain access to them as though they were public methods.

In Ruby 1.8 all we have to do is use the Object#send method.

To demonstrate:

class MyClass
    private
    def say_hello(name)
        puts "Let's go back to my place, #{name}."
    end
end

my_object = MyClass.new

> my_object.say_hello
Nomethoderror: private method `say_hello' called for #<MyClass:0x820b4>
	from (irb):8
	from :0

> my_object.send :say_hello, "world"
Let's go back to my place, world.

Touché!

Now, honestly, this strikes me as odd. Conceptually, I don't see why send should function differently from an ordinary method call with respect to access control.

The rubydoc for send says nothing of this, and there is some debate on the mailinglist as to whether Ruby 1.9's send will maintain this behavior.

But for now this can be very useful if you disagree with a class designer's method access choices.

One thing I hate about Ruby is that Ruby methods aren't closures.

For instance, this blows up:

hello_string = "Hello, world!\n"

def say_hello
    puts hello_string # bzzt! hello_string isn't in scope
end

say_hello # bzzt!

Which is a little odd because Ruby does support closures on procs:

hello_string = "Hello, world!\n"

say_hello = Proc.new do
    puts hello_string
end

say_hello.call # Hello, world!

It kinda sucks that every time I want to create a closure I'm forced to use the less succinct ".call" syntax.

So why can procs be closures while methods cannot?

After a bit of thinking I realized this comes down to a design tradeoff on whether or not we have to type "self" or "this" all over the place when writing methods as we do in Python and JavaScript.

In Ruby we don't have to do this, and Ruby accomplishes this by making procs and methods two different things with different scoping rules.

Proc bodies have a lexical scope like functions in Lisp and JavaScript, meaning that when Ruby encounters a free variable inside a proc body, its value is resolved within the context the proc was defined. This is what makes closures possible.

Methods are different, however. A method's context is the object to which they are bound. When Ruby encounters a free variable inside a method body, it assumes the variable refers to another method on the object, and this is what saves us from having to prefix same-object methods with "this" or "self".

To demonstrate:

irb(main):171:0> hello_string = "Hello, world!"
=> "Hello, world!"
irb(main):172:0> def say_hello
irb(main):173:1>     puts hello_string
irb(main):174:1> end
=> nil
irb(main):175:0> say_hello
NameError: undefined local variable or method `hello_string' for #
	from (irb):173:in `say_hello'
	from (irb):175
	from :0
irb(main):176:0> def hello_string
irb(main):177:1>     "Hello, world!"
irb(main):178:1> end
=> nil
irb(main):179:0> say_hello
Hello, world!
=> nil

Personally, I'm not sure I like this tradeoff.

Procs and methods are conceptually very similar. They are both composed of a list of arguments, a block of code, and a context in which the block is evaluated. I'm not sure they should be different things.

The way I see it, a method should just be a special case of proc that happens to have an implicit "self" parameter. In this case methods would inherit the proc scoping rules and therefore could be used as closures.

If this means we have to be verbose and type "self" to call other methods on the same object, I'm fine with that.

And in fact, this is how things work in JavaScript:

var helloString = "Hello";

var myObject = { 
    friend: "Kitty",
    sayHello: function() { 
        print(helloString + " " + this.friend);
    }
};

myObject.sayHello(); // Hello Kitty

Matz clearly recognizes that there are issues with Ruby's current scoping implementation, so maybe this is one of them.

But, hey, this kind of tradeoff may just be a Rubyish thing to do, and I probably dig closures more than most.

Oh, no problem. I'll just do a search.

And a short instant later...

Goddammit!

There's a massive game of tag going around the blogosphere. I've been tagged by Bill and Dave.

So here goes. Five things you didn't know about me:

1. I all but gave up Computer Science in favor of law my junior year of college. I even convinced my friend Evan to do the same... except he actually did :)
2. I've been to London, Paris, Amsterdam, and Zurich, but only set foot west of the Mississippi in May of this year.
3. I scored higher on the language portion of the SAT than the math portion.
4. I play piano.
5. I've been skydiving... twice.

I tag Ryan, Jeff, Kurt, Vinnie, and Anton.

Much is made of the pain of typing long variable names (or function names or class names), but code is usually read more often than it's typed. And when I'm reading code (even if it's my own), I'm grateful for names that err on the side of descriptiveness.

This means:

• navigationElement instead of navigation or nav
• queryString instead of query, queryStr, string, or str
• libraryLookupUrl instead of libraryLookup or url

The exceptions are common language idioms which any programmer could reasonably be expected to know (ie: cons in Lisp, def in Python, x as an index into array loops). These should be abbreviated as their meaning is more intrinsic and independent of the name.