Hm, I must admit the possibility to change a method supposed to do addition to a method that does subtraction does not excite me as much as the blogger.
Although it would be cool if programs could debug themselves that way, but I don't think we will see that all too soon.
It wasn't just the fact you can change it that was neat, but that the block was represented as a traversable structure (which you can then modify).
Alternatively, you can write blocks of code that get functionality added to them on the fly, that don't really belong in that block of code. Say you process some data, and you want to send an email notification before you process, and then log the activity after you've finished. But notification and logging don't really have anything to do with processing the data, and especially when they're scattered everywhere, it's a pain to manage. It'd be nice if we had it all in one place.
Traditionally, we've used observers to do this sort of thing. Observe some change in the processor or data, and then we log or send notification. Some people use Aspects, though it's not widely used.
I can see using this to change a processing block by adding on notification and logging code before and after. Or, if the processing block has a couple stages of processing, and you want to change one directly through metaprogramming, instead of building up structures to support it.
Yes, probably lot's of cool things can be done with it, some that even the inventors have not yet thought about. At first it seems like a recipe for disaster, though (debugging hell) ;-)
Although it would be cool if programs could debug themselves that way, but I don't think we will see that all too soon.