.NET Languages Weblog

Does Any Language Targeting the CLR Generate a Fault Block?

Mon, 28 Apr 2008 15:42:13 GMT

One thing I need to add to ExceptionFinder is the ability to handle fault and filter blocks. VB generates filter blocks, but I don't know of any language that generates a fault block. Supposedly, Boo...might. This post says it does (as try-failure), but the docs here doesn't mention that syntax.

I'm still going to add support for it (it's easy to generate a dynamic assembly with a fault block) but I'm just curious if any language actually uses the fault block. If you of one (other than IL :) ) please add it in the comments - thanks!

Create Your Own Language On Top Of The DLR

Wed, 23 Apr 2008 12:47:47 GMT

This article shows what it takes to have a language target the DLR.

My Languages Podcast on Spaghetti Code

Tue, 01 Apr 2008 00:59:14 GMT

I recently did a podcast on languages and the CLR - you can find out more here.

C# 3.0 Impressions

Sun, 16 Mar 2008 13:34:46 GMT

I've been using C# 3.0 for a while now, and here's what I think of some of the new features. Don't expect long, drawn-out explanations with code examples; this is basically a brain dump :).

Lambda Expressions. I love the syntax - it's so much cleaner than what it is in 2.0.

Type Inference. I haven't used it much, but that's because I keep forgetting it's there. I'm a fan of consistency, so I don't know if I want to mix using "var" with typed variables or just say go with "var" all the time. But I do like that we have the option of letting the compiler figure out the type for us. I realize this is primarily used with LINQ - I'll get to that acronym in a bit.

Extension Methods. Love 'em. I've written so many "helper" classes in the past, and the extension method approach cleans up the syntax so much. BTW here's a great resource on writing good extension methods. I realize the article is really about LINQ (again, I'll get the that acronym very soon!), but there's some excellent commentary on extension methods.

Automatic Properties. I use them, but I'm not entirely thrilled with them. Generally I only use them if I have mixed-accessibility of a property that doesn't need initialization during object construction. Plus, I don't like how it mixes code styling with "richer" properties. I definitely like them more than I don't, but there's some aspects with this feature that I'd like to see changed in the near future.

LINQ. See? I told you I'd get to this eventually! I still haven't used it. I love the idea of LINQ, but frankly I haven't had a pressing need to use it. It's probably because I haven't really forced myself to change my methods that have lots of foreach's with "where"-like checks to LINQ statements.

There. Overall I'm really happy with C#'s improvements. I've heard about some ideas for 4.0, and there's some things I'd love to see, like covariance and contravariance and great immutability support. There's also some things I'd love to see at the CLR level, primarily with Cecil-like features in Reflection, managed profiling and the ability to inject/modify code using a managed language.

Oh, one more thing I forgot about. I want tuples. Have you seen how tuples in F# make the TryXXX() patten so beautiful (go here and search for TryParse)? Amazing! Here's an idea of how it might look in 4.0.

Python for .NET

Sun, 16 Mar 2008 12:48:26 GMT

This is different from IronPython in that it seems like it allows Python devs to use .NET libraries; it doesn't compile the Python code to IL.

Saved By Blogging

Mon, 25 Feb 2008 14:17:47 GMT

Wow.

Assuming this story is true, of course... ;)

What I really love is that he used geekspeak ("what's the difference between GET and POST?" and "prove that P = NP") to pwn her.

More Discussion on Constructors

Fri, 22 Feb 2008 14:13:45 GMT

Here's another take on constructors in .NET, referring to the same article I mentioned here.

My Podcast With PolymorphicPolycast Is Up!

Tue, 19 Feb 2008 21:22:31 GMT

I just found out my podcast on PolymorphicPodcast was published - you can listen to me blab on and on about unit testing, code coverage and code analysis by going to this link. This was basically me going through some thoughts I've had on what it takes to write better code, which I plan to expand on at the fourth Twin Cities Code Camp.