November 17th, 2008


Art of Conversation comment feed

At metahacker's suggestion, I've added a second feed for the Art of Conversation blog, for the comments -- since I'm trying to run this *as* an ongoing conversation, the comments are often as interesting as the top post. (Or moreso.)

So if you're interested in talking about online conversation and community, I recommend adding the artofconvcmnt feed, as well as the original artofconv. The latter is the posts, the former is the comments. This way, you can follow the full discussion from LJ. (In theory, anyway. LJ hasn't begun populating it yet, but I expect stuff to start showing up sometime in the next day...)

Microsoft adding Code Contracts to C# / .NET

Fairly important news for anybody doing programming in the Windows world: Microsoft is continuing to steal all the best ideas from other languages, and in this case is adding Contracts to the .NET library.

Contracts have been around for a while now, but this is the highest-profile implementation to date. The high concept is that ordinary signatures aren't sufficient to completely describe the behaviour of a class: to really describe how the class *works*, with deep static checking, you need to be able to describe it in more detail. Classic examples of contracts include "values passed to this method must be non-zero", or "this method can never return null".

What makes Contracts interesting is that they allow much deeper static evaluation of the code, so that the compiler can ensure that the Contract is always true, providing warnings any time something happens that might violate it. They're kind of like assertions, but where assertions only work at runtime, many Contracts can be enforced at compile time. The implementation isn't quite perfect yet -- they've bolted Contracts into the library, not the language, so they're still a tad clunky yet -- but it already provides impressive power. (For instance, they are showing that the compiler implicitly tests for universal contracts such as potential divide-by-zero errors and null references.)

Along with Contract support, they are releasing a new tool called Pex, which "explores" the problem space and exercises the method in various ways, checking for assertion and Contract violations. Again, not a new concept, but this is going to be a much wider release than such tools have gotten before. As far as I can tell, Pex is intended to obviate much of the need for manually-written unit tests, by generating and exercising all the obvious tests automatically.

There is an interesting talk available online, which describes the new Contract system and Pex. Well worth watching for any serious programmer, since the implication is that Contracts are about to become mainstream -- whether or not you're programming in .NET, I expect that they'll become pretty commonplace over the next couple of years. And this is definitely for the best: if you're running a compiled language, Contracts are a good step towards reducing many kinds of common errors...


Yeah, this is why I am so fond of Olin: they're an imaginative bunch. Check out the One Velociraptor Per Child project, a thin but delightfully silly parody that a bunch of students there put together. I may have to get an OVPC sticker for my XO...

Introduction to F#

Continuing to lose far too much time today to watching useful presentations from the Microsoft PDC, here's another terribly interesting one.

Last night, I was talking with eclecticmagpie about the trend towards functional / declarative languages, so this Introduction to F# is quite timely. F# is Microsoft's entry into this field, and is steaming towards true productization: they say that it'll be coming out in a fully-supported commercial release next year.

It's a damned cool presentation, useful for anyone who wants to keep up on where programming is going. If you're new to the idea of declarative programming, this is a decent one-hour primer on how it works and how it's different from imperative; if you already understand the concepts, it shows how Microsoft is addressing it. It's worth watching the full hour, because he gets into parallel and asynchronous programming later on. It appears that F# isn't going quite as deep into parallelism as Fortress (at least, not yet), in that serial is still the default; that said, it looks like they are making parallel patterns really, really easy to write. Indeed, there are several points where writing a parallel version looks exactly as easy as writing serial, so I suspect I'd just do it that way from the beginning.

I call this one out as a good investment in the future for any serious programmer. My strong belief is that declarative programming is going to gradually become much more prominent in the next five years or so, because it's much more amenable to parallelism. (As well as simply being an efficient way to code up many problems.) Turning F# into a real product is Microsoft's stake in this particular ground, and is going to accelerate that trend, by making it downright easy to write declarative bits that interoperate cleanly with the rest of .NET. So it's well worthwhile to see this train coming before it rolls over you...

Future of C#

One more for today. This is less crucial for all programmers, but probably interesting to anybody who is working in the .NET stack or might be doing so.

The last presentation consuming my time today is Anders Heilsberg describing The Future of C#, mainly C# 4.0. I wouldn't say that there is anything dramatic happening here, but they are continuing to add major new capabilities to the language.

The big enhancement this time around is dynamic typing. Basically, while they are still focused on strong static typing, they've acknowledged that dynamic languages matter, and that you often want to mix C# with dynamic languages like Python or Javascript or Ruby. So they've formalized the way these interact, behind a consistent interface, so that you can simply declare a variable "dynamic", and it gets typed dynamically at runtime instead of statically typed. Static and dynamic objects can be used together intuitively, with the runtime dealing with conversations as necessary.

I have to say, I'm amused by this one, simply because the world seems to be finally realizing that the static vs. dynamic religious war is stupid. I mean, I'm currently working in ActionScript 3, which is more or less the current version of Javascript. That comes to much the same conclusion from the other direction -- it's a dynamic language that has wound up going *mostly* static, but allows you to still use dynamics when it's appropriate.

So I think this enhancement to C#, making it clean and easy to use dynamic components within the overall static framework, is a fine acknowledgement of reality, and should make integration generally easier.

There are several other new features, less crucial but still useful. They've added the long-begged-for optional parameters for methods, as well as named parameters. COM interoperability has been considerably improved, making it significantly less painful to write .NET programs that work with traditional Microsoft tools. (He shows an example of working with Excel, and how it's a more natural programming experience now.) And they've added some fairly subtle new concepts to support co- and contra-variance in parameter types, which allow certain types of obvious generic programming that weren't previously possible.

In the last few minutes, he talks about where things are going in future releases, 5.0 and further. Suffice it to say, they're starting to take metaprogramming seriously, opening up the compiler, turning it into a proper API so that you can do code at runtime, hook and enhance the compiler, generate strongly-typed objects at runtime, and so on. While this is old hat in many languages, the idea of having a Read-Eval-Print loop is pretty radical in C# (he shows the fairly modest code to write a dynamic C# command line, as one expects in dynamic languages). I suspect that this is going to open up a bunch of use cases for C# that were not previously practical.