Underwater

Remember on Fear Factor when they used have people go underwater and pick a lock or solve a Rubik's cube or eat some disgusting animal part? Did you ever think about how you would approach that challenge? I always think about these things. I don't know why, because I will never be on one of those shows, but if I were, I would have thoroughly considered my approach.

If I'm going underwater, and I need to get something done, I will be focused from the start. I've got 30 seconds' worth of oxygen in my lungs; I can't just dive in, turn a couple of flips, wave at the camera, and maybe plan my dinner menu for the week. If I do that, I'm definitely not going to get the lock open. Fortunately, as my body gets desperate for oxygen, the survival instinct will kick in, and I'll go scrambling for the surface. So I may fail, but at least I won't die.

Unfortunately I was not born with similar instincts for dealing with my computer. I have one thing I need to do. Maybe I need to send one email. Maybe I need to check tomorrow's weather. Maybe I need to make one tiny update to some web page. It doesn't matter what is. I need to hold my breath, dive in, do the thing, and get back to the surface. But my mind does not have the same fearful respect for the internet that it has for water.

I go in casually, oblivious to the danger, with no sense of urgency. I look at email, RSS feeds, Twitter, Facebook, CNN, Reddit. I willingly expose myself to every source of distraction conceivable. If I see anything interesting in one of these places, it pulls me further in. What's worse, if I don't see anything interesting in one of these places, I'm just stupid enough to think about where else I might look to find something interesting. It's a black hole. At this point I have already failed to meet my goal, to accomplish my one meager task, whatever it was. But the really tragic part is that I don't have the sense to scramble back to the surface to catch my breath. I'm already lost, and now the giant leech has attached itself to my life clock, gently sucking away the hours.

Computers are my livelihood, and I enjoy them. It's hard to imagine life without them, but sometimes I like to try. Yes, they may make our lives hundreds of times easier and more efficient, but as good as they are at helping us get things done, I think they might be even better at helping us not get things done. Don't get me wrong; I'm not going anti-tech on you. I'm just wishing there were a way to automate self-discipline.

There's no app for that.

Io - The Language

As a participant in the NashDL Book Club, I've been working my way through Bruce Tate's Seven Languages in Seven Weeks. To be fair, we only meet once every two weeks, and we're hitting one language per meeting, so in our case it's seven languages in fourteen weeks. The first language we looked at was Ruby, which is of course an interesting language, but one that most of us were familiar with already. The real fun of this book is learning new languages, so I'm excited to have moved on to language number two, Io.

It must be acknowledged that this is a terrible name for a programming language if only for its ungooglability. It might as well be named Stack Space or Garbage Collection. This dynamic language is primarily inspired by Smalltalk, which I have had very limited experience with. Io is prototype-based, which makes me relate it to JavaScript, but Io is more strictly prototype-based. In JavaScript you can make a function act like a class and use it to create objects, but in Io there is nothing that even resembles classes. Types of objects are defined by building up prototypes and cloning them. The genesis of all things is the clone method of the Object type.

Person := Object clone
Developer := Person clone
IOer := Developer clone

All types are wide open to be modified in most any way, similar to the way classes are in Ruby. Properties and methods can be added, removed, and redefined at any time. Of course, this opens the door to both magic and disaster, so hack responsibly.

Io has an extremely simply syntax and some handy features that lend themselves nicely to creating DSLs. For example, to define the meaning of curly braces, you just create a method called curlyBrackets. Same with squareBrackets. Io also lets you define your own operators. This takes me straight to when Uncle Bob said that what killed Smalltalk was how easy it was to make a mess. It looks to me like that part of the Smalltalk legacy has been preserved here. It's very cool, but it reminds me of Inception when Ariadne starts getting too creative with her architecture. Sure, she is able to fold the world over on top of itself, but then she's got some seriously agitated projections to deal with.

Io is not the fastest language out there, but it might make up for that with some nice features for concurrency and asynchronous i/o. Anyone up for a new implementation of node.js? Might be fun.

I don't know if I will ever use Io in real life, but I have found it useful for helping me to think in a more prototype-oriented manner, which is necessary for writing good JavaScript. I'm still working to make amends with JavaScript after years of trying to treat it like C#. I think it's starting to forgive me. Thanks, Io.

Whitespace: And Now, For Something Completely Different

We've probably all heard it said that any fool can write programs that a compiler can read, but a great developer writes programs that a human can read. Of course some languages lend themselves to human readability more than others. I have often heard Perl picked on as a "write-only" language. Well, I recently ran across a language that puts Perl in the clear.

Check out Whitespace. If you've got a place in your heart for ridiculous languages, you'll eat this one up.

On Software and Music - In With the Old

As one of the many software developers who are also musicians, I have always been fascinated by the frequent bundling of the gifts and passions for these two endeavors and what they have in common. I have always said that writing code and writing music feel a lot like the same process to me, like they're using the same parts of the brain. Music and code are certainly similar in many ways. Both need structure and coherence. Each work must be unique in some way, or it is meaningless. Both must follow some set of rules. What set of rules to follow is a creative choice. Sometimes you can even make up your own rules, but failure to follow them will pose a threat to the cohesion of the work. Once the rules are established, you may occasionally, carefully, and mindfully, make some real magic by breaking them.

Looking at these similarities causes me to wonder about their differences. If the creative processes are so similar, what about the products thereof? One difference I notice is that music seems to be much more durable than code. The software world is in so many ways all about "the new hotness." The music world also has this element, but old music is much more present in the world than old code. Not that old code doesn't have its own nostalgic place our hearts. This is the magic of Mame and cool projects like the AppleSoft BASIC Interpreter in JavaScript and FC64. It's why people buy Donkey Kong machines on eBay. The musical side of this nostalgia would be listening to Van Halen I or Synchronicity or Frampton Comes Alive or whatever you remember listening to as a kid.

But what about the work that we consider to be truly significant? In the music world we still study Stravinsky, Mendelssohn, Beethoven, Mozart, Bach, Gabrieli, even Gregorian chants, not as nostalgia, but as work that is still relevant and valuable today. Where is this reverence for history in software? What is the difference? Is it in the platform evolution? Each new computing device to hit the market seems to render last month's model instantly obsolete. The arsenal of musical instruments over the years has progressed more by expansion than by evolution. The new does not generally displace the old. We've added saxophones, steel-stringed guitars, drum kits, electric pianos, electric basses, synthesizers, and on and on, but the symphony orchestra still looks pretty much like it did three hundred years ago.

This is one of the things that I find so fascinating about all the recent movement in the field of functional programming. It's old! LISP was developed in the 1950s, and we're studying this approach today not because it tells where we've come from, or because we have fond childhood memories of it, but because it is valuable to us right now. I have never seen this happen before in this field. Maybe it's just because I'm getting old, but I'm intrigued and excited to see "the new hotness" can be something that is older than I am.

We Want the Func! - Moving Toward Functional Programming

In the last year I have heard/read where Uncle Bob has been talking about discovering the twenty-six-year-old treasure of a book The Structure and Interpretation of Computer Programs. It happened enough times that I decided to check it out. The book is available free of charge here. The language used in the book is Scheme, an implementation of Lisp. I hadn't written or read any Lisp since college, but even then I really liked it.

At the time I had no idea of the concepts of functional vs. imperative programming. We didn't talk about immutability; I just thought it was interesting that you had to use recursion where you would normally have used a loop.

About fifteen years later I found myself learning XSLT. While here we do have the <xsl:for-each> element, I once again discovered that if I wanted to count from one to ten, I had to use recursion. That didn't throw me so badly, but what did throw me was the <xsl:variable> element. Maybe it was just the name and my own notions of how a variable is used. I thought I should be able to do this:

<xsl:variable name="x" select="1" />
<xsl:variable name="x" select="$x + 1" />

But nope. Once x is defined, that's it. No one was there at that moment to offer me the term immutability, but there it was. Little did I know that a few years later, linear processing speed would be maxed out, having bumped its head on the laws of physics, and this concept would give traction to something of a programming revolution in pursuit of scaling via concurrency.

After a decade or so of studying Gang of Four and Fowler, honing our OO skills, now .NET geeks are delving into F#, JVM nerds are digging into Clojure and Scala, and Erlang and Haskell are finding their way out of the classroom and into the business world. Even though web developers have been writing client-side code in JavaScript for the last fifteen years or so, most of us never noticed what great functional capabilities it had until recently when jQuery showed us what kind of magic a more functional approach had to offer. And why should all that magic be confined to the client side? Along comes node.js, bringing all that non-blocking functional goodness to the server, or wherever you might need it.

Anders Hejlsberg, king of Turbo Pascal, Delphi, and C#, has been talking lately about the future of programming languages and how important functional capabilities will be to keep them moving forward. This video is a little over an hour long, and it's all good, but if you don't have that much time, at least watch his overview of what functional programming is, which starts about 21 minutes in. It is excellent. He says so much with the simple phrase, "more like math." He also says some interesting things about "islands of functional purity" in the context of more conventional data-oriented (mutable-state) applications.

So what is my point here? Simply that there a lot of us who might just be starting to feel like we've made the transition from procedural to object-oriented programming, and we need to be aware of this functional movement and do what we can to embrace it and adapt to it. It's a very different way to think about solving problems, and it's a lot of fun. Onward and upward! There's more to life than inheritance.

Breaking the Ice with IronRuby

I'm a Windows guy and a Ruby guy, so of course I was disappointed at the recent developments around Jimmy Schementi's job change and what Microsoft is doing with the IronRuby team. I want to believe what some other folks are saying about the reports of IronRuby's death being greatly exaggerated, but it still doesn't look too good to me. A few days after this buzz started going around, I started thinking about what I'm doing about it. I'm using Ruby on Windows quite a bit, and there are not a lot of us, but I'm doing all my Windows work on MRI (Matz' Ruby Interpreter). I have IronRuby installed, but I don't use it for anything but an occasional experiment.

If I really care about the future of IronRuby, I need to be a little more supportive, maybe even (dare I say it?) get involved. I recently discovered the new Iron Languages Podcast and learned that there are three (count them) IronRuby MVPs. I honestly didn't know there were any. Anyway, I got inspired to start trying to work IronRuby into my life somehow.

I am a little concerned about how compelling most not-already-Ruby-infected .NET developers will find IronRuby without any Visual Studio tooling. That makes it more of a .NET for Ruby folks than a Ruby for .NET folks. So I thought I would try using it for some of my normal Ruby stuff, the same way I might spike JRuby or Rubinius. Can I do some simple BDD with VIM, rspec, and autospec with Growl?

The first thing I did was to clean up my installation. If you don't have other versions of Ruby installed, the stock IronRuby install works just fine. They've replaced the commands ruby and gem with ir and igem, but if you install autotest or rspec or any other gem that you might call directly from the command line, you can run into conflicts if your MRI gems and your IronRuby gems are both in your path at the same time. I manually removed IronRuby from my path and added it to my pik list. Now I just use pik to choose IronRuby, and it handles the path changes for me.

By the way, if you have IronRuby installed in a directory with any spaces in the full path, it's going to cause you some trouble down the road with certain gems, so do yourself a favor and put it somewhere other than under C:\Program Files\.

I installed some of my favorite gems rspec, autotest, and autotest-growl, which all installed fine because they don't use native extensions. Then I got started on Uncle Bob's good old prime factors kata. You know what? It pretty much worked! The tests ran fine when triggered by saving files. I had a small problem with autospec's handling of Ctrl-C to force the tests to run on demand. It seemed to handle it twice, which caused it to exit, which was less than helpful. But other than that, it appeared to run just like MRI. Even my Growl notifications worked. Love me some Growl.

Now that I've got IronRuby acting like Ruby, I need to get it acting like .NET. I'll save that for another day. Stay tuned.

Hey, you got Ruby in my JavaScript!

I am a big fan of Ruby's Enumerable module. I has some crazy useful methods that get mixed into every array. I have said before that I wish I could somehow use Ruby's Enumerable module in every other language I use. I don't know about every other language I use, but if we're talking about JavaScript, it's pretty doable.

For example, let's look at the find_all method from Enumerable. According to the documentation, when called on an object enum and passed a block block, it returns an array containing all elements of enum for which block is not false. The following line will give us the integers from 1 to 10 that are divisible by 3:

(1..10).find_all {|i|  i % 3 == 0 }   #=> [3, 6, 9]

It's like a little query engine on your arrays. Don't you wish we could do this in JavaScript? Something like this:

[1, 2, 3, 4, 5, 6, 7, 8, 9, 10].findAll(
  function(x) {
    return x % 3 === 0;
  }
)  //=> [3, 6, 9]

Well, one very nice thing about JavaScript is that we can add methods to any object's prototype, and then any object of that type will have that method on it. In our case, we can add a findAll method to all Array objects. To make this work, all we have to do is execute this first:

Array.prototype.findAll = function(f) {
  var result = [];
  for (var i = 0; i < this.length; i += 1) {
    if (f(this[i])) {
      result.push(this[i]);
    }
  }
  return result;
};

Give it a try. Hey, you got Ruby in my JavaScript! Okay, to be fair, we can't really give Ruby the credit. It's just an example of higher-order function usage, but it enables me to give JavaScript a feature that Ruby has spoiled me with.

Enjoy.