You Think You Like Halloween?

I don’t think you like Halloween like this guy likes Halloween…

I’m glad to have helped in even a very small way.

Announcing Sudo for Windows

If you’ve used a Unix much, I’m sure you’re familiar with sudo, a command-line utility that lets you run things as the superuser. Not only it is very handy, but it is the basis for one of the better XKCD strips.

Sudo is one of those things I find myself wishing for in Windows, especially given the new(ish) UAC features in Vista/Windows 2008. There are lots of times when I just want to run something as administrator, dammit. Typing “sudo notepad2 C:\somewhere\foo.txt” would fit the bill.

I tried Sudo for Windows, but it made me type my password. That seemed silly, given that I don’t need to type my password anywhere else to run things elevated. There are probably other implementations of this out there, but it literally took less time to write my own than it would to crawl through all of them looking for the one I like best. All it does is execute whatever arguments get passed to it, but the program itself has the “require administrator” bit in the manifest, so the target program winds up running elevated as well.

Anyway, it’s in my arsenal. Visit here to get it in yours, too.

Announcing InhibitSS

Short story: I wrote a little tray app that will prevent your screensaver from running. Download it here.

Long story: I’ve been training for a marathon over the last few months, but a couple of weeks ago I hurt my foot and have been unable to run consistently. While I’m recovering (and hoping I’ll be well soon enough for me to be able to race), I’ve got to do something to keep in shape. One of the things I do is to ride my bike on a stationary trainer in front of the computer. While that works well, it’s a pain to unlock the screen if the screensaver kicks in while I’m pedaling, as it sometimes does. So I wrote InhibitSS, which runs in the tray and will prevent the screensaver from running, and therefore the screen from locking. Here’s what it looks like when it starts up:

Then, if you double-click it, it looks like this:

The red X indicates that the screensaver is inhibited.

I’m sure there are a dozen apps just like this. But this one has the feature that I had fun writing it. :)

C# Mixins

Update: Corrected terminology – it’s “generic functions” not “generic methods”.

Aside from macros, another nice feature that Lisp supports is mixins. In fact, this is one of the (very, very) few things I miss about C++. Of course, Lisp does it in a much more powerful way using something called generic functions. See here and here for a great description of generic functions in Common Lisp – it’s one of the cooler parts of Lisp, in my opinion, especially for someone like me who has come from a C++/C#/Java OO background.

Although not a tool for every occasion, and somewhat against the spirit of Inherit to Be Reused, Not to Reuse, mixins are nonetheless handy at times. Since mixins are generally implemented via multiple inheritance, they haven’t really been an option in C#…until extension methods came along. Now you can do something like this:

using System;

public interface TellNameMixin
{
    string Name { get; }
}

public static class MixinImplementation
{
    public static void TellName(this TellNameMixin subject, string prefix)
    {
        Console.WriteLine("My name is: {0}{1}", prefix, subject.Name);
    }
}

What we’ve done is to define an interface type and a corresponding extension method that adds functionality to that interface. Since any number of interfaces can be implemented on a type, we can apply our mixin to classes that have no other type relationship, or that already have a base class. Like this:

public class Craig : MarshalByRefObject, TellNameMixin
{
  public string Name { get { return "Craig"; } }
}

public class Program
{
  public static void Main()
  {
     Craig craig = new Craig();
     craig.TellName("Mr. "); // Prints “Mr. Craig”
  }
}

The best part about this is – as with all reuse mechanisms – there’s only one place where I have to change how TellName works. Obviously, if the Craig class was the only class I was extending, I could skip the mixin class and just use extension methods directly. But if I have additional types that I want to add this functionality to, and if those classes have no other type relationship (a situation I found myself in just today) then this might be handy.

Anyway, it’s not something you’ll use every day, but it’s worth knowing about.

Lisp, Too, Is Mainstream

You’ve seen me talk here before about the fact that I have been lately fascinated with Lisp. Sadly, I haven’t been able to spend the time I’d like with it, but I continue to read and think about it. And I’d really, really like to put in some serious time writing a real app (better: several) in Lisp.

So it was with great interest that I read Lisp, too, is mainstream. I like pretty much everything that Eric has written, and his LispCast screencasts are good, too. This article starts with Greenspun’s Tenth Rule (“Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp”) and extends it to a rather different conclusion:

My point is that it may be too late to start with Lisp so you don't have to reimplement all of its features. Because all of those new languages have already implemented them. At least what most people consider the important ones.

Or put another way:

I guess my point, through all this meandering, is that other languages did borrow a lot from Lisp. About half of it. And now those features are out there, in the world. And in the meantime, while they were borrowing, they got some new features of their own. Features like giant user bases, gazilions of libraries, corporate support, standards bodies. So Lisp has half of the features of Python. Java and Python are far from my ideal language---but so is Common Lisp. The idea that I would have to implement so much of Lisp on my own is a little overblown these days. And speaking of reimplementation: How much of Python's standard library does a complex Lisp program reimplement? How much of Python would you have to reimplement before you regret choosing Common Lisp?

And speaking specifically to macros, which I currently see as the single biggest weakness of C# when compared to Lisp:

Macros let you subsume more code into less code. Macros let you write more functionality with fewer lines. Macros let you abstract away boilerplate into new syntax.

But the corporate manager will say: if everyone writes their own syntax, my programmers can't read each other's code. So instead of having to learn a language once, they will have to learn a new language each time they approach a program for the first time. And the value of macros is lessened.

It’s enough to take the wind out of an aspiring Lisper’s sails. :) However, I haven’t given up yet. I have two questions that I still need to answer for myself before I draw any conclusions of my own.

1. Is the value proposition of macros (i.e. custom syntax/DSLs) different for small teams? And particularly for stuff I read and write only for myself? Because I’ve got a lot of code that falls into those categories.
2. Is the library situation really so dire? I find that I don’t actually wind up using third-party libraries all that much in C#, so either the BCL is extremely complete or the types of problems I’m solving are just naturally self-sufficient. Or I’m doing something wrong. :) Besides, when I cruise the Lisp sites, I actually see lots of libraries I could use. But maybe there’s some critical functionality that I’d have to write myself that would take a long time.

Of course, the answers to these questions are inherently highly subjective. Like pretty much any question touching on programming tools. If I can find a way to go write a fair amount of Lisp, I’ll get my answers. They will, however, be my answers. I’ll share them with you if I ever get there, but don’t expect them to help you much. :)

MSDN Low-Bandwidth Rendering Option

One of the common complaints with the MSDN website is the fact that the pages are pretty fat. The team has done a lot to make this better, but there's still some stuff in there that not everyone needs.

 

If you're interested in an extremely skinny version of the MSDN docs, give the new LOBAND rendering format a try. To use it, stick (loband) - inlcuding the parens - at the end of an MSDN URL, before the .aspx. For example, the documentation for System.Xml.XmlReader is normally at http://msdn.microsoft.com/en-us/library/system.xml.xmlreader.aspx. But if you surf instead to http://msdn.microsoft.com/en-us/library/system.xml.xmlreader(loband).aspx, you'll get the new, low-bandwidth rendering of the page. There's a link at the top of the LOBAND rendering that lets you make it permanent via a cookie (you can turn it off later via a similar link).

 

It makes quite a difference. On my machine, I see the regular version at about 98KB, and the LOBAND version at just over 18KB - and the 98KB doesn't count the TOC tree, which doesn't render in the LOBAND version. Not a huge deal for those on high-bandwidth connections in the US, perhaps, but there are lots of people who don't fit that description.

 

Note that the team already has planned improvements for the next regular update of the site. But don't let that stop you from letting them know if you have any ideas about how to make it better. You can drop a comment here or contact me - I'll make sure it gets sent on.

 

And no, I didn't have anything to do with implementing this - I'm just blogging it. :)

Hobocopy x64 Build Available

I finally got around to hacking together an x64 version of hobocopy, my little utility that copies files even if they are locked. Note that you might need to install the 64-bit C runtime (vcredist_x64) in order to get it to work. Both the updated binaries and vcredist_x64 are available at the SourceForge download page.

 

Enjoy! Of course, if you really like hobocopy, maybe you'd consider becoming the maintainer.