Ever since I got back from vacation, it’s been all about the Morning Coffee. I’m happy to be getting a daily post out, but I haven’t written anything deep in several weeks now. My one non-MC post in the past two weeks was The Virtuous Cycle of Virtual Platforms which frankly I wrote over a year ago for internal usage and adapted for my blog after reading Dare’s post.

One of the reasons for my lack of “deep” posting recently is post vacation re-engagement. Also, things at work that I can’t blog about (yet) have been taking my attention. But I worry that this daily MC post is causing me to focus on “shallow” blog topics. Since I’m trying to average a post per day, that means at least two non-MC posts every week. Of course, more than two non-MC posts a week would be just fine.

• On the XNA Team Blog, Michael Klucher announces the XNA Game Studio Express Update is coming in April. Among the new features are Vista compatibility, 3D audio, bitmap fonts, game icons and most interesting the sharing of compiled XNA games. Currently, the only way to share something you build with XNA with the community is by sharing the source code, which is less than optimal. For more, check out the XNA GSE Overview presentation by Mitch Walker from GDC.
• Speaking of gaming consoles, Sony’s “big” announcement is a Second Life clone? Kotaku thinks “this is going to be one of those features that people didn’t realize that wanted until they get it.” Personally, I doubt that very much, but what do I know about game consoles? I just play, man.
• Jafar Husain suggests a way to do Ruby symbols in C# 3.0. Sort of. He defines an extension method that returns the name of the property defined in a lambda function. On the plus side, it’s strongly typed. On the minus side, this.GetPropertySymbol(o =\> o.Name) isn’t as easy to type as :Name. (via DotNetKicks)
• While pseudo-symbol support is fairly verbose, Scott Guthrie goes thru some of the new language features for terser syntax: automatic properties, object initializes and collection initializes. While I like object and collection initializes, I’m not really sold on automatic properties. Personally, I like the VS prop snippet approach, where you automate the creation of the property once time when it’s authored rather than leaving the shortcut syntax in the code in perpetuity.

Ruby’s symbols are often talked about in terms of efficiency – taking up less memory and executing faster. While these are both laudable goals, symbols are more than just performance improvers. The ability to name things is valuable semantically. Take a look thru p&p’s Composite UI AppBlock and you’ll see strings used as names for things all over the place. It’s great for loose coupling, you see. But how do you tell the difference between a string used as a name and a string used for some other reason like user input? You can’t.

Rails makes extensive use of symbols – anyone who has Rolled on Rails has seen “scaffold :recipe”. That’s just the tip of the iceberg. Rails uses symbols extensively across both ActionPack and ActiveRecord (and probably others I’m not familiar with). It’s a great approach, but one that’s unique to Ruby as far as I’m aware.

Several languages, such as Python, have the concept of a Tuple built into the lanugage. One of things it’s used for in Python is multiple return values. So you can call “return x,y” to return two values. Of course, C# can only return one. If you need to return more values, you have to define out parameters.

LINQ / C# 3.0 / VB 9 support the idea of anonymous types, which is similar to a tuple. The big difference is that, because they’re anonymous, they can’t leave the scope they’re defined in. In other words, they’re great within a function, but if you want to pass them out of your function type-safely, you have to define a non-anonymous type for them.

Interestingly enough, F# supports tuples, though it a bit of a hack. Since the CLR doesn’t support tuples, F# basically defines different Tuple classes for up to seven tuple parameters (i.e. Tuple<t1,t2,t3,t4,t5,t6,t7>), For .NET 1.x, it’s even worse – they have to define different type names (Tuple2, Tuple3, etc). Ugh.

Update: Robert Pickering pointed out that F#’s tuple implementation is entirely transparent inside of F#. He’s right – I was writing from the perspective of a C# developer using F#’s implementation of tuples. Maybe I need to be looking closer at F#?