Visiting the Future in Io

So seven weeks might be a bit optimistic.  I spent the greater part of a week trying (unsuccessfully) to get Io to compile on my Ubuntu box.  The intricacies of compiling C code from source have been one of many obstacles that have kept me away from contributing from open source.  I haven't had any luck before and Io was no exception.

Eventually however I stumbled across the windows binaries and gratefully dual booted into my Windows 7 partition.  The binaries gleefully worked on the first try.  Io was a very nifty language once I finally got to use it.  Slots, terminology I had actually heard first from a Java library, make up an object.  Objects are just collections of slots.  Slots contain objects.  Confused yet?

It isn't confusing if you know Io's cousin, Javascript, already.  Both languages are prototype languages, they don't use classes but merely clone existing objects for inheritance.  Objects are basically hashes (i.e. dictionary).  In Io everything is an object including methods.

Io has some interesting behavior, particularly in relation to concurrency.  Instead of the pre-emptive multitasking I'm used to in Java, Io goes for coroutines instead that politely pass execution from one to another.  Two currency constructs, one I'd heard of and another foreign, are also extremely easy to implement in Io.  Actors, the known, are simply instated by send an asynchronous message to an object (messages are basically method calls).  The unknown was a construct known as Futures.  These are simple objects from most perspectives, the difference being that a Futures value is filled by an asynchronous call.  If you try to access the object before the call finishes, you automatically block execution while you wait.  All of this behavior is baked into the object, no extra code required to access the value.

I've already started digging into Prolog and I hope to give you some idea of what I find soon.  Hopefully my seven weeks in theory won't double in practice.

Metaprogramming and the Magic Black Box

As you might have read in my last post, I'm trying to get some additional reading in this year.  One the of the books I got for Christmas was Bruce Tate's Seven Languages in Seven Weeks.  I've polished off the reading for the first language, Ruby.

Overall this is an enjoyable book so far.  One point of irritation however is the references to answers at the back of the book, which were never published.  Not only is this irritating because it should have been an easy typo to fix, but because the best parts of the book so far have been the example problems.  I thoroughly enjoyed thinking through the problems and the lack of answers (which I wouldn't miss as much if references had not been made to them) reduces my understanding of the author's perspective.  Frequently I found myself wondering if I was missing some basic aspect of the language (particularly a bit of syntactic sugar in Ruby) when solving a problem.  Perusing blogs helped to some extent, but often I felt like the example answers I could find were missing some elegance that Tate had in mind. If they didn't have some significance, why did he choose that problem to print?

Metaprogramming in general has been one section of Ruby that I've been extremely interested in learning how to apply appropriately.  Seven gives a good synopsis and certainly shows how it can remove boilerplate code.  It is part of the magic of the Rails framework, but I still remain unconvinced as to its place as a part of a programmer's standard kit.  I think there is a balance to be found between boilerplate overload and metaprogramming negative space.  When you hide the context of an operation inside the black box of metaprogramming I think you lose a fair amount of perspective into the design of a program.  Simpler (concise) becomes more complex (abstraction).  We risk losing ourselves in the metaphors.

Hopefully, I'll find a use case that makes me really appreciate the magic box of the method_missing and related tricks in Ruby and other metaprogramming toolsets.  Until then I'll probably just piggyback on the frameworks like Rails that have used it so well.  If you feel like explaining why method_missing is awesome, please do so on the StackOverflow question below.