The easiest way in C# using .NET 3.5 to distribute work across cores is to use the ThreadPool static class. I found however, it wasn't quite as effective as it could be so I rolled my own.

I've been rather quiet lately, while I continue to labor away on Heron in the background. Rather than freezing the feature set and moving as fast as I can towards an official v1.0 release of Heron, I've decided to make it a bit more sexy by parallelizing the reduce and map operators.

Many languages have an associative collection data type built into a language, for example Python has a dictionary, Lua has tables and JavaScript has objects. I want something similar in Heron,  but I will be putting my own spin on it.

I've recently posted Heron version 0.9 . The major new feature with this version is the module system. I am quite happy with the new module system because it makes it possible to write code which offers the convenience of using (what look like) global or static variables but without all of the disadvantages.

At Autodesk, like many companies, we produce our API reference documentation directly from programmer comments. In this blog I share a draft best practices document that I am hoping we can start using for our developers, when they write code comments.

C# 4.0 will apparently have significantly more powerful dynamic programming language features. 

I  show here the design of the module system under consideration for Heron.  

I'm about to put the finishing touches on the Heron design for its big 1.0 release, by putting in the module system. I left this for last thinking that it would be trivial. Boy was I wrong!