Read this post, and you'll understand why the CLR isn't really ready for Smalltalk. Heck, I can grab the call stack from inside BottomFeeder - a running Smalltalk application.

There's been a lot of commenting on this post from a few days ago on the CLR and dynamic languages. Normally, comments automatically close down when an item falls out of the RSS feed. With the level of interest, I'm leaving this one open. There's a single item feed for it here, if you want to follow the fun in your aggregator. I'll close the comments down once things start to die down, most likely.

Panopticon sets out to explain why they had to break compatibility from VB to VB.NET - and in the process, explains one of the main problems with the CLR for us dynamic language folk: the CLR can host any language, so long as it contorts itself into a C# style shape.

Sriram Krishnan posted something interesting about the CLR garbage collector:

I was talking to a former MSFT employee who worked on the CLR team. The conversation drifted towards languages used to implement virtual machines. Here's what I learnt.

The CLR's Garbage Collection%A0was initially written in Lisp by a Patrick Dussud (I can't find a blog). This code was then run through a Lisp->C converter which was then cleaned up by an intern.

That's interesting - it demonstrates to me that when MS needed something done fast, they knew well enough not to do it in C or C++ (assuming this story is correct, of course). On the other hand, if you do what they did:

• Write a sub-system in language 1
• Generate the C from the resulting code
• Manually modify the results

Can you actually maintain the results? Generated code is always hard to grok. It's one thing if you write in a high level langiage and then generate C (never actually looking at the C) - you can look at the C as something akin to byte code in that case. But if you muck with the generated code before deploying it? I'm not sure that you end up with something you can maintain...

Sriram Krishnan attended a TechEd conference, and has a good set of notes posted. I noticed this in passing:

Every attendant gets a number of points, and he can give any number of these points for any feature he believes is important. The features with the most points get implemented. The last time the board took a vote, the edit and continue feature got 0 points, which means it probably won't become implemented in the feature, unless a lot of pressure is applied by developers and clients.

Hmm - I thought I've seen other people (from MS, but I could be mistaken) say that this would be added to "Whidbey". In any event, I find it fascinating that a development board would think this is so irrelevant - really makes a Smalltalker scratch is head and go "huh?"

Seems that it's not just me - The .NET Guy isn't pleased either:

I read posts like this one detailing the new generics system in .NET] and it makes the baby Jesus want to cry. Where is the latent typing that made generic programming so powerful? The monstrosity they've cooked up is basically useful for any type of generic programming where you don't actually USE the thing... meaning, containers. *sigh* I think it's time to start coding in IronPython.