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.

Hobocopy Needs a New Daddy (or Mommy)

I enjoy the process of sharing some of my work as open source. One of my more successful efforts in that area has been Hobocopy.

 

Like most (really, all) software, it's not done. There are any number of things I'd like to add to it, and I still get occasional requests from people for enhancements or bugfixes. But, due to one thing and another, I just haven't been able to get around to doing any work on it for months. So I'm asking you, dear LazyWeb, if you know of anyone who would be interested in adopting this poor, neglected, digital offspring of mine. 

 

I'm open to whatever arrangement that maintains the MIT nature of the license, so if you'd rather move the code somewhere else or transfer the copyright, that's cool with me. Or we can keep it where it is and I can set you up as a contributor.

 

Hobocopy is written in C++. Not very good C++, mind you, but C++ skills are still required. Although with sufficient work, we could probably factor out the bit that needs to be in C++ and rewrite everything else in C#. I'm happy to help with design direction via email, I just don't have time to hack.

 

Anyway, let me know if you're interested. It's a good tool and I'd love to see someone pick it up and move it forward.

Speaking at DC ALT.NET Thursday

Lately I've been enjoying going to the DC ALT.NET meetings. I can't say I've figured out what ALT.NET is supposed to mean, but the DC version appears to equate to smart people talking about interesting things, so that's good enough for me.

 

Anyway, I shot off my mouth (big surprise!) about how cool I think Lisp is at the last couple of meetings, so I figured it might not be a bad idea to offer to do a somewhat more structured talk about it some time. I don't really do much public speaking any more, but I happen to have a little presentation ready about what I've learned about (and from) Lisp, so I offered to give it and they accepted. If you'd like to hear it, come on down on Thursday.

MSDN Updates

Yesterday was a big day for me with respect to MSDN. There were a pair of "the new replaces the old" moments.

 

The first event was the one Larry Jordan amusingly subtitles "There will be only one!" What happened was, the old MSDN finally got turned off - the MTPS-based version of MSDN is now the only version running. http://msdn2.microsoft.com now redirects to http://msdn.microsoft.com. That means no more fun URLs like https://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fileassoc.asp. Now it's http://msdn2.microsoft.com/en-us/library/bb776847.aspx. Ahh - that's better.

 

Since I helped write the Microsoft/TechNet Publishing System (MTPS), which sits behind the new, one-and-only MSDN website (and the TechNet and Expression websites, for that matter), it was sort of cool to see it "take over".

 

The other thing we did yesterday was to update the MTPS REST API. It's still very much a prototype (i.e. things are broken) but we wanted to push a version out there that has some of our latest thinking in it. Most notably, this release sketches out what we think we want to do for writes. That's right - we intend to support community-authored changes to MSDN (the website supports that now in the form of tags and wiki-like annotations, in case you didn't know).

 

Although I should point out that the writes aren't implemented yet in the REST API because we haven't fleshed out the story for authentication.  But you can see the idea. For example, to add a new tag to an item you'll be able to PUT to http://labs.msdn.microsoft.com/restapi/content/b8a5e1s5/en-us;vs.90/tags/add-tag. And to delete a the foo tag added by user candera you'd DELETE http://labs.msdn.microsoft.com/restapi/content/b8a5e1s5/en-us;vs.90/tags/foo/users/candera. For convenience, we're also planning to support POST to those endpoints with a hidden form parameter of _method, which is set to PUT or DELETE as appropriate. It's just too convenient to be able to drive the service from a browser during development not to do that.

 

Another big change is what lives at ~/content. In this release it's a link to the ~/sites part of the API. In MTPS parlance, a "site" is the host part of a URL (e.g. the "msdn" in http://msdn.microsoft.com). Underneath those are "iroots", which is a lot like a vdir (e.g. the "academic" in http://msdn.microsoft.com/academic). The reason ~/content links to ~/sites is that via ~/sites you can find your way into the TOC tree of any of the content in MTPS…or at least you could if it were hooked up properly everywhere. Still, you can see the idea.

 

That said, we've decided that the link to ~/sites is ugly and we hate it. :) So we'll have to figure something else out there. Maybe a set of virtual TOC nodes that unifies all the TOCs - one node to bring them all and in the API bind them. Or something - we're still noodling on that one.

 

Other changes: we've added ETags and Expires headers to all resources (currently everything is hardcoded to expire 24 hours in the future), fixed some of the encoding problems, added an XHTML DTD where appropriate, and of course there are the obligatory bunch of minor bugfixes. We've also done some slight reorganization of the URLs to fit our evolving understanding of the model, but most things have remained unchanged. I'm curious to hear if anyone has played with the service at all - if you have any questions or feedback, do feel free to contact me.

Friends of the MSDN Library Facebook Group

Larry Jordan has put together a Facebook group ("Friends of the MSDN Library") to aggregate people who have ideas about how MSDN can improve. I have a vested interest in this, as I make part of my living contributing to the code that makes it happen. So join up…think of it as a way to help put my daughters through college. :)