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!
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.
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.
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.
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.
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.
