Hank,
>The speed difference between static and dynamic languages is basically eliminated by innovations in the DLR, based on real-world testing.

Is this specifically based on your Boo experiences ? (If so, pls tell me more <g>)

From my POV the DLR mechanisms for addproperty()-functionality follow closely the Ironpython implementation
(add a new dict for such properties) - speaking of expando objects. So there is a lookup penalty for dynamic properties
even if the code is of "traditionally compiled" C#/VB CLR.

In the traditional compiled languages you still have a heavier hit on reflection compared to exec and eval in IPy,
but running in IPy is generally slower compared to pure C# - just like vfp function call is slower than C++ function call,
method calling in IPy is slower than C# for instance. [That it is good enough fore most tasks is on another page
as well as the lousy startup hit Dotnet shares with java, but not with CPython or vfp]

What is truly amazing is the fact that IPy general speed is sometimes faster than CPython -
especially when taking the slowness of the Jython interpreter into account as base line for a managed runtime.
But that is also a different topic.

Other currently argued concepts (as the prototype based approach of Googles javascript compilation)
I haven't read about as implemented in the CLR/DLR languages AFAIR.
[vfp had some nice ideas - I view the vfp inheritance implemetation as prototype based,
while the addproperty() is akin to adding a new key into the vfp equivalent of the dict]

> So now it's down to what language does the job better for a given individual, in a given context: there is no more straight-jacket.
Not so fast...
There are some API's (Datagrid... grrr) which explicitely need set/get property accessors or steer you again into ADO.Net.
So while its getting better, there are static crystallized contexts still in the fwk.

Again: if you can shed some light on the Boo mechanism (aka "true" .Net objects even for addpropertied), tell us....

regards

thomas