Everything that can be done in Boo can be done in C#, without the DLR. So it's not a matter of whether it can be done, but rather how one wants to work. At the least, Boo's compiler does for one what the C# compiler could do if the designers wanted it to, without breaking static typing at all. In C#, base.<method> performs the same as dodefault() or super(); the latter two are to my mind more descriptive (although the lengthier version can be used in Boo as well).

Rodrigo's point is that the compiler should be smart enough to figure these things out; so he made a compiler that figured these things out. Not having to make methods virtual in order to be overridden; not having to type overridden to override them; etc. It's all about the compiler being smarter.

At the most, Boo's compiler does more, as I indicated. For example, if I have a button b, then I can define an eventhandler and an eventhandler method like so:

b.Click += def(o,e):
b.Text = "Clicked"

All the rest that is missing from the C# eventhandler code is just confusion waiting to happen: words that have to be there, but which give no additional meaning. Code should be self-documenting, as an ideal; having to type a bunch of words that lend no additional meaning gets in the way of moving toward that ideal. Of course, this effect varies by person: for those who are simple-minded like myself, keeping it simple is the key to productivity.

Finally, there is the issue of static typing: with -ducky set on at the compiler level (a checkbox in SharpDevelop, on the Compiling tab under Project), all variables are duck-typed by default (but can be specified as desired). Even without -ducky, type inference will handle the typing of variables that are set directly to object instances. Where speed is useful, static typing is available.

Boo has other strengths, too, but I didn't focus on them. It's a great language for writing other languages, as DSLs or entirely different languages (using its compiler pipeline extensibility). In fact, it appears that VFP.Net was actually being written in Boo, based on the error numbers. That accounts for it having gotten as far as it did (nothing I know accounts for it having stopped in its tracks).

The SharpDevelop implementation is pretty mature: the debugging is right on, better than either the IronPython debugging is at present, and better than VFP.Net was. I suspect that's because Daniel Grunwald has been working with it for 5 years, so it has had time to mature.

Hank

>>I've been exploring Boo as a dynamic language, and I'm seeing that it's a great fit for VFP developers who want to work in .Net, but don't want to give up the dynamic language features of VFP. Here's a blog entry I posted, http://blog.prosysplus.com/2010/07/boo-as-dynamic-language-part-1.html , on the subject of subclassing.
>
>I'm a bit confused about some of the things in the blog:
>
>>Notice that in VFP, we don’t concern ourselves with whether a class method is Virtual or not: we can override it as we will
>Doesn't VFP support PROTECTED and HIDDEN ?
>
>>And we can still call the code in the parent class, when we want to in our code.
>True - but so what? Are you implying that the same cannot be done in NET
>
>>Also, we can modify the class more than once: with a Virtual method, you get one shot at overriding it, and that’s it.
>Don't understand what you mean by this .......