CraigBlog

Clojure Concurrency Tutorial Available

craig-andera — Fri, 09 Apr 2010 18:45:14 GMT

Update: all six parts are now available. That’s over two and a half hours of Clojurey goodness.

Update: There are now downloadable versions available in wmv and mp4 formats in a variety of resolutions. Just click the download button by each module. Also, the refs module is now up.

A while back, I wrote up some slides on concurrent programming in Clojure that I used at a DC ALT.NET presentation. Since I had them ready, and since Pluralsight has a great infrastructure for doing online training (it’s called Pluralsight On-Demand!), it made sense for me to record the content and make it available. So I have.

I’m happy to announce the immediate availability of the first four parts of my six-part Clojure concurrency tutorial, a screencast. You can find it here. It is freely available, and no registration is required. The final two parts will be available in less than a week.

I wrote the tutorial from the perspective of a .NET programmer who is new to Clojure. I don’t focus on the language itself, but rather the concurrency support in it. However, I don’t assume any prior knowledge of Clojure, so we start by covering just enough language syntax to get us through the demos. From there we dive into vars, atoms, agents, refs, promises, futures, and all sorts of good stuff.

If you’ve been reading my blog, you’ll know I’m a big fan of Clojure. One of the reasons for this - but not the only reason - is its fantastic support for concurrent programming. I like to say that it provides “sanity in the face of concurrency”. If you’re interested to learn more, check out the tutorial, and please – let me know what you think!

The Zero-Argument Overload of Any

craig-andera — Fri, 02 Apr 2010 20:23:00 GMT

I'm a pretty big fan of Linq. I use it all the time in my C# code. But it's a relatively big library, and I've never studied it exhaustively, so from time to time I come across some neat corner of it I've never seen before. In fact, that happened just the other day.

I find that I'll frequently write test code that looks like this:

Assert.AreEqual(0, collection.Count());

or the inverse:

Assert.AreNotEqual(0, collection.Count());

I've done it often enough that I have thought I ought to write a pair of extension methods on Assert called IsEmpty and IsNotEmpty. That's probably still a good idea, but it also turns out that the Linq extension method Any (normally used to test if at least one element of an enumeration meets some criteria) also has a zero-overload method that simply returns true if the enumeration has any elements at all. So I could rewrite the above tests as:

Assert.IsFalse(collection.Any());

and

Assert.IsTrue(collection.Any());

respectively. While having Assert.IsEmpty and Assert.IsNotEmpty extension methods would be better (perhaps your test framework already provides them), this is still a handy little thing to know about.

Implementations of Slideshow in C# and Clojure

craig-andera — Wed, 17 Mar 2010 15:44:00 GMT

As I promised I would the other day, I went ahead and implemented my stupid little slideshow app in both C# and Clojure. It was an interesting exercise, the more so because I’m not entirely sure what conclusions to draw. I may have more to say about this at some point in the future, but for now I thought I’d just put up the code and share some general observations. So, you can find the C# version here, and the Clojure version here.

The app is pretty simple. It starts a low-priority thread that lazily populates a list of filenames that are descendants of a particular directory. Meanwhile, a timer procedure randomly selects one of the filenames out of the ones that have been found so far and invalidates the screen. The repaint simply draws the image centered on a fullscreen window with a black background. If no images have been found yet, then it prints “Working…” on the screen instead.

The Clojure version isn’t really an app, because I wrote all this code really quickly and didn’t bother giving it a main() function, but other than that they’re about as similar as I could make them, given that one is running against Swing on the JVM and the other against Windows Forms on the CLR. I suppose I could have written the Clojure one against Windows Forms as well using ClojureCLR, but honestly it was simply more interesting to me to use Swing, as I’m not familiar with it. And this is anything but a scientific experiment.

For the C# version, I eschewed the Forms designer to keep it closer to the spirit of the Clojure one. And for something like this, where I’m just blasting raw pixels at the screen, I think that was a reasonable choice.

I wrote the Clojure version first. Perhaps that was a bad choice, since it meant I spent a lot more time on the Clojure one, since I had to figure out all the little details, like how to center an image in a region. It certainly made the C# version a lot easier to write, since I was pretty much just translating. But the C# version probably would have been easier for to write in any event, since I’ve been writing C# professionally for almost 10 years, and Clojure in my spare time for less than two.

One thing that surprised me a bit is that the Clojure version turned out to be not much shorter than the C# version. Indeed, if I had put closing braces on the same line as the statement they close (which is like the Clojure style I use), I’d bet they’re about the same. I had expected it to be quite a bit more compact, since, as I’ve said before, my experience with Clojure has been that it generally lets you be more concise. In this case, I suspect it has to do with the fact that I had a lot of Swing-related code, which doesn’t lend itself strongly to the sorts of concision that Clojure supports. Or it could be the fact that I’m a Clojure n00b, and just don’t know how to structure the code to hit a good balance of terseness with readability. Certainly, I could make it a bit shorter by inlining calls to things like make-frame. Other recommendations as to how better to write either version would be more than welcome.

Both versions of the code are pretty rough, as I wrote them essentially while I was waiting for stuff to install on a VM. I’d definitely clean them up more if I were going to do anything with them, but I figured it was better to get it up here than to wait potentially forever to get it polished. Really, I’m just trying to point out that not all my code looks this crappy. :)

You’ll note that in the Clojure version, I use an atom to store the list of filenames. That’s not because I’m taking advantage of Clojure’s awesome concurrency support, it’s because it was a convenient thing to do. Note that the C# version doesn’t bother with synchronization at all, since I’ve only got two threads, and one is only reading, and one is only appending. If I wanted to get fancier with the threads (e.g. have another thread doing look-ahead loading of the next image), then I might have to start doing synchronization. I’d be in good shape on the Clojure side then, since not much would have to change, and the fact that Clojure values are immutable really helps. I don’t think the C# version wouldn’t need too much work, but I’d have to think about it more to be sure, and it would depend on exactly what I was trying to do.

It’s apropos of nothing, but it made me smile that the C# version required PInvoke to get a fullscreen window, and the Swing one just supported it out-of-the-box.

Being familiar with Visual Studio was a definite benefit when working with the C# code. I’m not very facile with the debugging capabilities of Emacs/SLIME, which is what I use to develop Clojure, and when I had problems it took me a little longer to figure them out. That said, having the REPL was really awesome, and it really makes me hate the Immediate Window in Visual Studio by comparison. It would be interesting to try some of the other Clojure IDEs to see how they stack up.

Neither version of the code has much in the way of comments. Sorry about that. :)

Anyway, that’s my pile of unstructured thoughts. Hope it’s of interest, if not value, to at least some of you. And as I said, further discussion, rewrites, comments, and criticism are wholly welcome.

Creating a Lazy Enumeration of Directory Descendants in C#

craig-andera — Wed, 10 Mar 2010 13:57:18 GMT

Update: it turns out that Clojure has a built-in file-seq function (thanks to Stuart Sierra for pointing this out) that already does exactly this, making Clojure the winner hands-down for brevity :) Seriously though, arguments about “batteries included” aside – although a valid point of consideration – I still think it’s interesting to consider the bits of code below.

Yesterday, I posted some Clojure code that showed how to create a function that would lazily return all the descendants of a directory. Here’s the code again:

(import [java.io File])

(defn dir-descendants [dir]
  (let [children (.listFiles (File. dir))]
    (lazy-cat 
     (map (memfn getPath) (filter (memfn isFile) children)) 
     (mapcat dir-descendants 
      (map (memfn getPath) (filter (memfn isDirectory) children))))))

Towards the end of the post, I tossed off a somewhat off-hand comment:

Two things struck me about writing this code. The first is that it’s really, really compact. It would be even smaller if it weren’t for the calls to memfn, which is just there so I can use a Java method as if it were a Clojure function. The second is that it was a bit of a mind-bender to write, although having written it I find it fairly easy to read. But I suspect both of those things would also be true if I attempted to write the equivalent C# (including the laziness, probably via a “yield return” implementation of IEnumerable somewhere), although it would almost certainly be at least somewhat more verbose.

Well, Chris Sells called me on that one. Here’s the equivalent C# code he came up with:

using System.IO;
using System.Collections.Generic;

namespace ConsoleApplication1 {
    class Program {
        static IEnumerable GetDirectoryDecendants(string path) {
            foreach (var file in Directory.GetFiles(path)) { yield return file; }
            foreach (var directory in Directory.GetDirectories(path)) {
                foreach (var file in GetDirectoryDecendants(directory)) { yield return file; }
            }
        }
    }
}

I think quantitative comparisons of code terseness are generally pretty silly, but - subjectively - when I look at that it seems just as compact as the Clojure version. So I stand corrected on that one. A few other observations:

Chris included namespace and class statements. Clojure has equivalents for these, but I omitted them. Omitting them from the C# version would make it even shorter.
The C# version can actually be made more lazy than the Clojure one because of the CLR’s Directory.EnumerateFiles method, as pointed out by John in the comments to yesterday’s post. That’s pretty cool. I could, however, take advantage of this if I used ClojureCLR instead of the JVM-based Clojure.
I said that writing the Clojure version was a bit of a mind-bender. To clarify, the bendiness came from the behavior of lazy-cat, and I think primarily because I’m relatively new to Clojure. The “yield return” in the C# code – which is the key to the laziness – gave me similar pause when I first encountered it years ago. And although I’m comfortable enough with it now, the two yield return statements in Chris’s code made me pause for a moment to convince myself it would work without consuming stack. So I think there’s probably some inherent complexity in the laziness that – like many things – is no big barrier once you internalize it in either language.

So I haven’t proven anything to anyone, not even myself. That said, having worked with Clojure a bit and C# a lot, I’m still left with the impression that Clojure is generally more compact. It will be a few years before I can say whether that’s a good thing or not (or even whether it’s true), since I tend to think working with a language on that time scale is the only way to really get to know it. I will do two things, however. The first is to show you another bit of code in both Clojure and C#. First, the C#:

private static IEnumerable Fibs()
{
    yield return 0; 
    yield return 1; 
	
    int a = 0; 
    int b = 1; 
    while (true)
    {
        int temp = a + b; 
        a = b; 
        b = temp; 
        yield return b; 
    }
}

Next, the Clojure:

(def fibs (lazy-cat [0 1] (map + fibs (rest fibs))))

Hopefully it’s obvious from at least one of these that they’re meant to compute the Fibonacci sequence.

Maybe someone can come up with ways to make the C# more compact: I would welcome such suggestions. And I’m not trying to have a Clojure-versus-C# contest here – those are stupid, like saying, “Which is better: a hammer or a drill press?” But language comparisons are still interesting in that you generally wind up learning something you didn’t know about at least one of the languages.

The other thing I’m going to do is to implement my slideshow app (the thing that had me writing the directory recursion function in the first place) in both languages and post them here. Until Chris posted, I was pretty sure I knew how they’d stack up. Now I’m just curious! Maybe you are, too.

Thanks, Chris, for keeping me honest.

Creating a Lazy Sequence of Directory Descendants in Clojure

craig-andera — Tue, 09 Mar 2010 14:23:00 GMT

Update: it turns out Clojure has a built-in function file-seq that does (almost) exactly this. The difference is that you get a lazy sequence of File objects, not paths. Hooray for "batteries included"!

I was playing around with Clojure this morning, attempting to write a little photo viewer application. As part of this, I wound up writing a function that produces a lazy sequence of all the files that are descendants of a given directory. I was pretty happy with how it turned out, so I thought I’d share it. Here’s the code in its entirety:

(import [java.io File])

(defn dir-descendants [dir]
  (let [children (.listFiles (File. dir))]
    (lazy-cat 
     (map (memfn getPath) (filter (memfn isFile) children)) 
     (mapcat dir-descendants 
      (map (memfn getPath) (filter (memfn isDirectory) children))))))

The key bit here is the lazy-cat, which returns a lazy sequence – it doesn’t evaluate the second expression (in which I walk into the children of the current directory) until someone asks for the next element in the sequence. In other words, even though this function looks recursive, it’s not. Because lazy-cat returns right away, the “nested” call to dir-descendants happens after the stack has been popped. This is totally awesome, because it means I can call dir-descendants and it’ll return right away. So I can start displaying pictures without having to wait for the entire directory tree to be enumerated.

Two things struck me about writing this code. The first is that it’s really, really compact. It would be even smaller if it weren’t for the calls to memfn, which is just there so I can use a Java method as if it were a Clojure function. The second is that it was a bit of a mind-bender to write, although having written it I find it fairly easy to read. But I suspect both of those things would also be true if I attempted to write the equivalent C# (including the laziness, probably via a “yield return” implementation of IEnumerable somewhere), although it would almost certainly be at least somewhat more verbose.

On the Utility of TestPropertyAttribute

craig-andera — Wed, 24 Feb 2010 13:13:54 GMT

On the project I’ve been working on lately, I’ve been using the unit test stuff that ships with Visual Studio/.NET, in the Microsoft.VisualStudio.TestTools.UnitTesting namespace. For my purposes, I’ve found it to be adequate, and it has the benefit that I don’t need to include any additional libraries.

I recently came across one use of it, however, that took me some time to figure out. Primarily because the documentation on this feature sucks pretty bad. It’s the TestPropertyAttribute, and it’s useful enough to be worth knowing about. So I thought I would share.

If you read the documentation for TestPropertyAttribute, your first reaction might well be the same as mine was: “Huh? That looks like it adds precisely no value over any other custom attribute I might write.” Because the docs show that to retrieve the value, you reflect against the test method it’s defined on, which is pretty silly. However, in experimenting, I found that there’s an equally poorly documented property on the TestContext class called Properties that you can use to get the value of this attribute.

Still, if you only need a value within the TestMethod itself, there’s not much value in it, as it’s no better than just hardcoding the value within the body of the test. Where TestProperty shines, though, is that the properties for the current test are also available during the TestInitialize method. That means you can bung a whole bunch of common setup code into your TestInitialize method, and parameterize its behavior based on properties defined on the tests themselves. A little code might help demonstrate what I mean:


   1:  using System;

   2:  using System.IO;

   3:  using Microsoft.VisualStudio.TestTools.UnitTesting;

4:

   5:  namespace Demo

   6:  {

   7:      [TestClass]

   8:      public class ThingTests

   9:      {

  10:          // Note that we have to have a TestContext, and it must

  11:          // be named TestContext

  12:          public TestContext TestContext { get; set; }

13:

  14:          // A simple field that we're going to initialize to

  15:          // some value in the Initialize method.

  16:          private string _thing;

17:

  18:          [TestInitialize]

  19:          public void Initialize()

  20:          {

  21:              // Obviously we could do something much more complex here.

  22:              if (TestContext.Properties.Contains("thing"))

  23:              {

  24:                  _thing = TestContext.Properties["thing"] as string;

  25:              }

  26:              else

  27:              {

  28:                  _thing = "default";

  29:              }

  30:          }

31:

  32:          [TestMethod]

  33:          public void TestAgainstDefaultSetup()

  34:          {

  35:              Assert.AreEqual("default", _thing);

  36:          }

37:

  38:          [TestMethod]

  39:          [TestProperty("thing", "non-default")]

  40:          public void TestAgainstCustomSetup()

  41:          {

  42:              Assert.AreEqual("non-default", _thing);

  43:          }

  44:      }

  45:  }

Basically, we’ve got a field _thing that we usually want to leave at the default value of “default”, but in some tests we want to override to some other value. Moreover, we want to override it in the Initialize method, since that’s where we’re doing our setup that’s common across tests. – maybe we have fairly complicated setup that needs to differ only slightly in some tests. So we use the TestProperty attribute to set a property named “thing” to whatever we like. Then, in the Initialize method, we can use TestContext.Properties to check for the presence of that value and take appropriate action.

I’ve made the code intentionally trivial to more easily demonstrate the concept, but I’m sure you can visualize more realistic scenarios where this might come in handy. For example, I’ve used it to customize which directory my Initialize method operates on.

2009 – The Year in Review

craig-andera — Tue, 05 Jan 2010 13:04:36 GMT

With only six posts the entire year, 2009 was my lightest ever for blogging, although I continue to be active on Twitter (here). I don’t see that changing in 2010. Still, as is my custom, I post herewith a review of 2009, both personal and professional.

Looking back on my review of 2008, it seems that 2009 was a year of relative stability for me. I continued to work on pretty much the same stuff: primarily MSDN, but a few side projects whenever I could wedge in some free time. And outside of work, family consumes the bulk of my time, although I still manage to run and to occasionally do something else fun (like fly the Black Shark – ping me if you want to join us!).

The MSDN work has remained interesting, particularly in giving me the chance to work on Visual Studio 2010 itself. That’s right, I have code that will ship in the box! Specifically in the bit that supports offline help. It was quite an experience to work on so large a project, and I’m definitely looking forward to installing the final bits when they are released later this year.

A few random highlights from the year:

I bought an iPod Touch, which I totally love. I use it constantly, and if it ever broke I’d buy another on in a heartbeat.
Clojure remains the most interesting programming language I know. I donated twice in 2009, and would encourage you to do the same (donating just once would be fine). Even if you don’t care about Clojure - although any serious programmer owes it to themselves to check it out - I assure you that Rich is doing a lot to advance the state of the art in concurrent programming and is worthy of your support.
I read a graphic novel version of “The Hobbit” to my five-year-old…four times.
We made some progress on the basement, but am still (somewhat depressingly) not done.
I started using git seriously, and think it’s pretty cool.
I ran in a track meet for the first time since college. And didn’t suck…as much as I thought I would.
I started playing bass again. Badly, but I don’t care.
I saw four movies in an actual theater: Earth, Terminator, Harry Potter, Star Trek. That’s roughly four more than I usually see, at least since the kids were born.
We did lots and lots of travel: I was away from home for a cumulative total of over two months last year, including one trip to Asia. Alice and the girls were away for around three months if you add it up, including a second trip to Asia without me. Crazy.

As for what 2010 holds, I’m honestly not sure. On the personal front, it would be great to finish the basement. But bigger than that by far looms the shadow of Kindergarten, which our older daughter will enter in the fall. I’m sure it’ll be a big transition for everyone around here, particularly in the mornings, which tend to run on the late side most days. But we’ll handle it like we handle everything else. And I’m sure we’ll keep traveling, but hopefully not quite as much.

On the work front I really have no idea. I’m continuing to work with MSDN, and that will go on for at least a bit longer, but the life of an independent contractor is filled with uncertainty, and there’s the distinct possibility I’ll have to do a fairly serious (and possibly lengthy) search for work at some point. But as I’ve said before, it’s the rare challenge that doesn’t pose an opportunity.

Good luck to you in 2010!

Kim Wolk Gets a Blog

craig-andera — Fri, 30 Oct 2009 12:03:23 GMT

Excuse me while I blow the dust off the ol’ blog here.

So I see that Kim has a blog now. Finally. About time. See, Kim is one of the most effective people I’ve worked with in my career. And I’ve worked with her on many different projects for coming up on 15 years now. If she has something to do say, it’s worth listening to.

Subscribed!

MSDN Lightweight Mode

craig-andera — Wed, 05 Aug 2009 13:54:29 GMT

Long time, no blog. Mostly I update on Twitter now (http://twitter.com/craigandera) – it’s just easier to hurl a 140-character tidbit out than it is to write one of these posts. And I’m nothing if not lazy. But a reader posted a comment over here about MSDN Lightweight Mode. I checked it out, and it’s pretty cool, so I thought I would share it here on the blog, since I know not everyone watches my Twitter feed.

Anyway, have a look at http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates(lightweight).aspx (for example) and see what you think. I like it. I particularly like the fact that I can view just C# code (or just VB, or just whatever), as the noise generated by seeing all the languages is probably my only complaint with the loband view, which I still love and use as my primary interface to the MSDN website.

I have no idea if this is an official thing, or an alpha that will disappear tomorrow, or what. Although I’m still doing work for MSDN, I only heard about this via the comment that Robert dropped on my blog. So hopefully I won’t get in trouble for sharing it, since I found out about it in public. :)

Check it out and see what you think.

MSDN Loband Rocks

craig-andera — Thu, 02 Apr 2009 14:03:18 GMT

I mentioned MSDN Loband a few months ago. Well, they’ve updated it, and the update kicks some serious butt. Check it out here (the root of the MSDN library) or here (the docs for System.Xml.XmlReader, which show a more typical page). Note the navigation links on the left side, particularly the absence of the tree, and notice how much more streamlined – and therefore faster – the HTML is. I even had a friend tell me that it works pretty well on an iPhone over 3G…in New Zealand!

Now, once you’ve decided you like this version much better than the old one, click the “Persist low bandwidth view” link in the upper right corner and rejoice in the fact that you will always get this view.

I can pimp this one with a clear conscience because I had nothing to do with implementing it. Kudos to the team.

Using Extension Methods to Verify Assumptions

craig-andera — Wed, 18 Mar 2009 14:02:36 GMT

I was working on something with Tim yesterday, and between us we came up with what I think is a pretty cool trick. We were defining some extension methods on XElement and friends that make it easier to work work XHTML. Something like this:

doc.Html().Div(“foo”).Div(“bar”).Value

Which would pull out the text content of a div with a class of “bar” that was a descendant of a div with a class of “foo”. All well and good, but one of the problems we were trying to address is that we didn’t want to proceed if there was no div of class “foo”. A NullReferenceException would be thrown, but we wanted something more specific. So we came up with this:

public static T OrThrow<T>(this T obj, Exception e) {
    if (obj == null) {
        throw e;
    }
    return obj;
}

Which in turn allowed us to write this:

doc.Html().Div(“foo”).OrThrow(new MyException(“no foo”)).Div(“bar”).Value

The clever bit is that the OrThrow extension method is generic on the type it’s invoked on, and it returns that type, so you can insert it into a chained expression and you don’t lose any intellisense. And because of type inference, you don’t actually have to specify the type (you don’t have to type OrThrow<IEnumerable<XElement>>), which cleans up the expression a bit.

This approach is more general than just XHTML, of course. Really, it allows you to insert arbitrary assertions/checks into a series of chained calls using a fairly natural syntax (for some value of “natural”). Nothing you can’t do other ways, but we liked the way this came out enough to want to share it.

Hard Links in Windows Do Not Update Immediately

craig-andera — Fri, 13 Feb 2009 14:05:06 GMT

I was pretty excited when I saw mklink appear. Filesystem links can solve a lot of annoying problems, which is why you see them used all over the place in Unixy systems. Although, like salt, the key is to use them sparingly.

Which is why I’m so annoyed that the Windows version is pretty much completely useless. Soft links are only recognized in some contexts, but hard links are the real offender. Try this from an elevated command prompt:

> cd C:\temp
> echo foo > a.txt
> mklink /h C:\temp\hard-a.txt C:\temp\a.txt
> more hard-a.txt
foo

So far, so good. Now try this:

> echo more >> a.txt
> more hard-a.txt
foo
> more a.txt
foo
more
> more hard-a.txt
foo
more

WTF? My hard link doesn’t update immediately? That sucks!

From experimentation, it seems that it only updates after you’ve actually accessed the link once. Since one of the things I’d like to do is hardlink files into my Dropbox synchronization directory, this is pretty much a non-starter – they’ll never appear to be updated, and therefore will never sync. Unless I visit every file, which is pointless, because if I was going to do that, I could just copy them. Which is what I’m trying to avoid.

I’m more than willing to believe I’m missing something here, but if so I don’t know what it is. My best guess is that this is a bug in the filesystem caching code (I’m on Windows 2008).

Days like this make me want to switch full-time to my Ubuntu machine. Also not perfect, but at least the novelty makes me less sensitive to its shortcomings.

What Is All the Fuss About How You Can Write DSLs in Lisp?

craig-andera — Mon, 05 Jan 2009 18:30:33 GMT

I saw Chris’s recent post, and felt compelled to respond, despite the fact that I’m pretty sure I’m going to regret it. :)

Here’s what he says, abridged:

(when (and (< time 20:00)
(timing-is-right))
(trade (make-shares 100 x)))

IMO, that's not a DSL -- that's just a set of function calls in an existing language.

The short version of my response to this is: “Yes! Exactly! That’s a feature, not a bug!” On to the longer version.

This argument, as a question of semantics, is fundamentally doomed to remain unresolved, unless someone can magically provide an exact definition of DSL that a) has no imprecision, and b) everyone agrees with. I’ll just pass on waiting for that to happen, and make my own observation:

A set of function calls in an existing language is generally preferable to a completely separate language. Particularly if it’s the language that you’re using to write the rest of your system. Sure, there are cases where using a specialized language is the thing to do, but over the last few years I’ve come to have a lot more - what’s the word? respect? fear? caution? – anyway hesitance around introducing additional languages into the development process. It’s not rare to see C#, SQL, XSLT, XPath, NAnt XML, regular expressions, and four or five other grammars floating around in the development lifecycle of a single process, and it’s got a real price. If nothing else, it means that not everyone can work on every part of the system. Throw in the fact that some of those are hard to debug, or have conflicting metaphors, or different performance characteristics, and it adds up.

So yes, one of the reasons that I’m excited about Clojure is that it’s a Lisp, and as a Lisp it is flexible enough to adapt to the point where I often don’t need a DSL. Or, if you like, where my DSL is also a Lisp. That doesn’t mean “I never want to use a DSL” or “I always want to use Lisp” – all things in moderation. It certainly doesn’t mean “You shouldn’t use M” – how the hell would I know what you need? But for me, I think it’s nice to have a tool that gives me the choice.

2008 – The Year in Review

craig-andera — Wed, 31 Dec 2008 20:35:09 GMT

It’s the end of the year, and although I skipped 2007, it is my habit to take a look back here on matters personal and professional. To whit:

I blogged a lot less this year. There are a number of reasons for that. The main one is that I’m just not as interested in blogging as once I was. I think that comes with the increasing “inward focus” my career has taken. I just find that more and more, what matters to me is what matters to me, not what matters to everyone else. That’s not a judgement or a boast, just an observation. It’s quite liberating: for example, I can go look at weird languages (see below) and not worry about it too much. :)

If you really can’t get enough Craig, you can always try me in appetizer size over on my Twitter stream. I seem better able to post a few dozen characters than a few paragraphs these days.

Career-wise, 2008 continued the shift I started in 2007 away from lots of small projects towards one big one. If I remember right, by the end of 2006 I’d worked on about seven different open source and proprietary projects, at a max of something like five simultaneously. That was too much, and I was feeling burned out. These days, pretty much all my professional time goes to a contract at Microsoft, where I’m working on the next version of Visual Studio. That has been very interesting for a variety of reasons, not the least of which is that it’s related to the work I’ve done on the MSDN REST Web Service.

Of course, the most significant event of 2008 had nothing to do with web services: it was the birth of our second child, daughter Susan. She was a cranky newborn, but has since turned into a charming and active baby. Needless to say, having two kids has really changed my life. I’m still coming to terms with giving up my free time – a painful process for me.

Not that I have no free time, of course. If I had none, I wouldn’t have been able to train for and run a marathon. But maybe I shouldn’t have talked so much smack in that post – Engberg whupped me good, and now I have to run another one. I think maybe this time I’ll make qualifying for Boston my stretch goal. Along the way, I’d also like to run a sub-20:00 5K. That’s much more my type of thing – I’m a fast runner, not an endurance runner.

This year saw my fascination with Lisp continue and even deepen, as is obvious from a variety of posts here. My latest interest on the parentheses front is Clojure. I made one (sort-of) provocative post about it, promised to say more, and never did. Well, given how not into blogging I am lately, I’m not sure whether I ever will live up to that promise. So go check it out for yourself: it really is an awesome language. Stu’s book is a good way to get started.

Here at the cusp of the new year, I don’t really know what 2009 will hold for me. I have a pretty good idea that the Microsoft work will continue for a while, but of course as an independent there’s always an increased level of uncertainty. But I like to think that it’s a rare problem that doesn’t yield an opportunity, so I’m optimistic.

On the family front, obviously we’re looking forward to watching both kids continue to grow and flourish. 2009 will be Ellen’s last full year of preschool, and of course Susan will likely start walking, talking, and doing all sorts of things. We hope to take family trips to Taiwan, Hong Kong, and Alaska, too.

On the professional front, I really want to spend more time working with Clojure. I’ve got some ideas for some real apps I can write, since that is, after all, the only true way to learn a language or platform. Plus it gives me a chance to run Ubuntu regularly, which I’ve been enjoying as a departure from the ordinary. (Clojure runs on Windows just fine, BTW.)

In the personal realm there are the running goals I mentioned earlier. I also hope to continue to fly Falcon, and maybe even DCS: Black Shark, which looks really sweet. If I somehow magically find extra time, and the basement finally gets finished, maybe I’ll even start playing bass and/or drums again.

Wishing you all the best in the new year.

A C# REPL (in Clojure)

craig-andera — Wed, 19 Nov 2008 19:43:24 GMT

It’s no secret that I’ve been interested in Lisp for quite a while. Lately, that has meant Clojure. Clojure is a new Lisp dialect that runs on top of the JVM. That means it has the power of Lisp (macros, dynamic typing, etc.) combined with the power of the JVM. The synergy reminds me of an old bumper sticker I saw years ago: “C: combining the speed of assembly with the power of assembly.” We’ve moved on a bit since then, but still. :)

Anyway, you should check out Clojure. It is easily the most exciting technology I’ve seen in years…probably since I first saw .NET in June of 2000. Even beyond just being a Lisp that actually has vast libraries (one of the main complaints against Lisps of the past) is the fact that there are some truly brilliant features of the language above and beyond what other Lisps sport.

One of the cool things I’d heard was that Clojure will run on top of IKVM.NET, which is a .NET implementation of the JVM. I figured that if there were a reasonable story for .NET interop, I’d be able to use Clojure to drive .NET code in a REPL. A REPL is a Read-Eval-Print Loop, which is a fancy way of saying “an interactive programming command line”. It’s like the immediate window in the Visual Studio debugger on steroids, and its absence is one of the increasing number of things that makes C# painful to use as I gain proficiency in more advanced languages.

Yes, I said it: C# is not an advanced language. If you think it is, then in my opinion you don’t know enough programming languages yet. :)

Intentionally provocative statements aside, here’s how you do it:

Download and unzip ikvm.net. No installer required.
Download Clojure. I recommend grabbing the head of the Subversion tree rather than the release that’s on the website.
Build Clojure by running “ant jar” in the clojure directory. You’ll have to install Ant to do this if you haven’t already.
Run “ikvmstub mscorlib.dll” to create mscorlib.jar, which will create the Java wrapper classes for the stuff in mscorlib.
Launch a Clojure REPL via “ikvm –cp \path\to\clojure.jar;\path\to\mscorlib.jar clojure.lang.Repl”.

Now you have a working REPL, in which all the types in mscorlib are available to be driven by Clojure, which is most definitely an advanced language. Here’s a very simple example (the results of running the commands are indicated by =>):

(import '(cli.System DateTime))
=> nil

(new DateTime)
=> #<DateTime 1/1/0001 12:00:00 AM>

(.get_Now DateTime)
=> #<DateTime 11/19/2008 2:31:02 PM>

(.ToString (new DateTime) "R")
=> "Mon, 01 Jan 0001 00:00:00 GMT"

You get the idea.

Of course this is probably only useful as an exploratory tool: if I were writing Clojure for real, I’d write it against the JVM, not against IKVM.NET. But I use the excellent SnippetCompiler all the time now, but it’s still not the quite same thing as a real REPL, so I’m excited to have a real REPL available.

And really, the reason I’m posting this is that I’m hoping it will be a sort of gateway drug for you, and that what this will really do is kick off your interest in Clojure itself. The website is a pretty good source of information, but you can also check out Stu Halloway’s Programming Clojure book. It’s available in Beta form here. I’ve been tech reviewing it, and even the early beta looks pretty good.