C# REPL

I started a new job recently that has taken me from a primarily interpreted, dynamically typed existence to one that is primarily compiled and statically typed. More specifically, I have gone from Ruby back to C#. This transition is only around my day job; I still love dynamic languages. But since I spend a good bit of time at work, this has affected a significant chunk of my programming life.

So what is my primary pain point coming back to the .NET world after a couple of years of peace, love, and Volkswagen minibuses? No surprises here; it's Visual Studio. In my day-to-day work I do everything I possibly can in VIM. So light, so immediate. Please don't make me open Visual Studio. It is so slow in everything that it does, even just opening and closing. You know, I'm not always creating a multi-tiered enterprise solution with three UI alternatives and seven WCF services. I very often want to write just one or two lines of code to clarify my understanding of some language behavior or some detail of the framework. It is at these times that I most resent waiting two minutes for the IDE to open. And please don't make me create a new solution just to run one line of code. Can't I just get straight to the language for a second?

One thing that Ruby got me addicted to was the instant feedback afforded by irb. Irb stands for "interactive Ruby." It is nothing unique; it's just Ruby's REPL. If you're not familiar with this term, a REPL is a read-evaluate-print loop. It's a command line shell in which you can type a line of code and have it execute immediately and print the result. For you Visual Studio folks, it's kind of like the Immediate Window, but it doesn't require a paused executing application.

Of course the REPL was not born with Ruby. I think it originated with LISP (before I was born), but you get one with Python, Scala, Haskell, Perl, Prolog—lots of languages. Modern web browsers with good debugging tools provide a REPL for JavaScript, but I prefer the one you get with Node. You might notice that these are all non-Microsoft languages, but my first experience with a REPL was in BASIC, and it was there in the version that came with MS-DOS back in the early 80s.

What is so special about a REPL? If programming is the way we communicate to a computer what we want it to do, must there be so much ceremony around saying anything at all? Writing an application is like writing a book. A small program might be more like a personal letter. But what if you just want to say something, or ask a single question? What's the largest integer value? Can you implicitly cast a float to a Boolean? What happens if I try to add a decimal and a null? What date is ninety days from today? Can you square a list of integers in one line of code? This is where the REPL shines. It's more like a conversation.

If you're like me, you've been spoiled by a REPL in another environment, and now you're spending your days in .NET, you've got to be mourning the loss of that instant feedback. If this a luxury you have never had, I'm telling you now what you've been missing. The good news is that there is a C# REPL in Mono. I don't know why I have not heard more talk about it, but it is a big deal to me. It is totally worth installing Mono for, even if you use it for nothing else.

Just head over to mono-project.com and install Mono. You don't even need MonoDevelop (although it is worth checking out). Add Mono's bin folder to your path, and you've suddenly got this at your disposal:

C# in a REPL. No Visual Studio. No project. And if that's not cool enough for you, it's Mono, so it works on OS X and Linux, too. Use wisely. Enjoy.

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.