July, 2004

Posts
  • Eric Gunnerson's Compendium

    TechEd Whiteboard with Anders

    • 2 Comments

    At TechEd 2004, Anders did a whiteboard talk. Recommended.

    (From Dan)

  • Eric Gunnerson's Compendium

    C# 3.0? You haven't even shipped 2.0 yet?

    • 21 Comments

    One of my readers commented (and I'm paraphrasing here):

    Why are you asking me about features for the next version of C#, when the 2.0 version hasn't even shipped yet?

    A fair question.

    One of the problems that we have in the tools division is the long lead time between the time when we're done with a product and the time that it's actually available to our customers. Delta a few small items and some bugfixes, the C# compiler is essentially done for Whidbey, so that's why we're thinking about the next version.

    We've always had this offset, but because we're attempting to expose our designs much earlier than we have in past, it may look strange from the outside. As involving customers early on in design becomes more common, this should be less weird.

    Hope that explains things a little better.

  • Eric Gunnerson's Compendium

    Memories of Youth

    • 13 Comments

    I remember the hot summer days of my youth. Our backyard patio had ants. I had a 5” magnifying glass. You can guess the rest.

    I've always had a soft spot for the power of focused sunlight, though I never took it as far as the creators of Melt Man did.

    Reading Jeremy's post on his Fresnel Lens makes me pine for those days.

  • Eric Gunnerson's Compendium

    using - It's not just for memory management

    • 16 Comments

    When we designed the using statement waaaay back in the first version of C#, we decided to call it using because we thought it had other purposes outside of the usual use:

    using (StreamWriter writer = File.CreateText(”blah.txt”))
    { ... }

    Today I was responding to a customer suggestion, in which he suggested language support for the ReaderWriterLock class, so it could be more like the built-in lock statement. Unfortunately, ReaderWriterLock.AcquireReader() doesn't return something that's IDisposable, but it's pretty easy to add that with a wrapper class.

    I spent about 15 minutes writing a wrapper, then I had a thought, did a google search, and came across this article, which already has it done. Plus, the version in the article probably wraps the whole class, and has likely been tested.

  • Eric Gunnerson's Compendium

    Anders Hejlsberg - Programming data in C# 3.0 #

    • 6 Comments

    Dan pointed me to a new video on Channel9 about some of the things we're talking about for C# 3.0

  • Eric Gunnerson's Compendium

    Stevens Pass Summit Lakes (Grace Lake)

    • 3 Comments

    Last Sunday, we went on a short hike to the summit lakes at Stevens Pass Ski Area.

    It was the first hike for us this season, and the first one with canine company.

    The real trail starts at the top of the Brooks lift (roughly centered in the photo). But to get there, you get to climb 900' up a steep jeep trail (well, you can walk straight up the hill if you want). We started at 8AM to miss the heat, so it wasn't bad.

    The trails to the lakes are fairly easy - mostly up and down, but the trail is pretty overgrown in places, so you'll need to spend some time pushing through underbrush.

    The lakes are typical alpine lakes - shallow, and very pristine. I didn't take pictures at all of them, but here's one of the very tiny ones.

    Recommended, but my knees are a bit sore after the hike down.

  • Eric Gunnerson's Compendium

    Not sure what to make of this...

    • 3 Comments

    Go http://www.ilovebees.com/. Wait for it.

    then, perhaps go here and here.

    I really don't know what - if anything - this is. But whatever it is, it's interesting...

  • Eric Gunnerson's Compendium

    JetBrains ReSharper 1.0 now available

    • 5 Comments
    JetBrains (of IntelliJ fame) has shipped V1.0 of ReSharper
  • Eric Gunnerson's Compendium

    What have Microsoft blogs meant to you?

    • 21 Comments

    I'm doing a few slides on blogging for a meeting that the C# team is having this Friday, and I need some good customer quotes to put on the slide.

    So, if you have comments about the C# team bloggers, please leave me a comment.

  • Eric Gunnerson's Compendium

    Managed Minidumps

    • 2 Comments

    Scott talks about Managed Minidumps

    It's a debugging thing...

  • Eric Gunnerson's Compendium

    Answer: What is the lifetime of local instances?

    • 15 Comments

    Answer to this poser

    I wasn't sure the answer to this question was observable, so I wrote a short program:

    using System;
    class Early
    {
      ~Early()
      {
         Console.WriteLine("Early Cleaned Up");
      }
    }
    class Test
    {
      public static void Main()
      {
         Early e = new Early();
    
         GC.Collect();
         GC.WaitForPendingFinalizers();
         Console.WriteLine("Done Waiting");
      }
    }

    The output from this is

    Early Cleaned Up
    Done Waiting
    

    In other words, there is no guarantee that a local variable will remain live until the end of a scope if it isn't used. The runtime is free to analyze the code that it has and determine what there are no further usages of a variable beyond a certain point, and therefore not keep that variable live beyond that point (ie not treat it as a root for the purposes of GC).

  • Eric Gunnerson's Compendium

    Poser: What is the lifetime of local instances?

    • 2 Comments

    A reader wote me to ask a question about variable lifetimes. Consider the following code:

    class Mutex

    {

           public Mutex(string name)

           {

                 hMutex = Kernel32.CreateMutex(null,false,name);

                 Kernel32.WaitForSingleObject(hMutex,0);

           }

           ~Mutex()

           {
                 Kernel32.ReleaseMutex(hMutex);

           }

    }

    class MyClass

    {
           void MyFunc()

           {

                 Mutex m = new Mutex("MyGlobalMutex");

                 

                 // (some code here which accesses, or calls functions which access, a shared resource...

                 // Note: no explicit reference to m, especially no call to destroy or clean up m!)

           }

    }

    Will the mutex will be held for the duration of method MyFunc()?

    Answer to follow in the next post

     

  • Eric Gunnerson's Compendium

    Why language features die, and language extensibility

    • 7 Comments

    Rick Byers wrote (some time ago):

    Thanks for the awesome post Eric. I'd be interested in hearing more detail about the sorts of things that cause features to be rejected. Is it common to reject a feature that you think would be valuable only because of syntactic compatibility limitations (parser ambiguity, breaking change, etc)?

    What are you thoughts on how language evolution should work in general (outside the confines of C#)? Do you think it would be possible to have languages that could more readily accept the type of extensions you've wanted to make to C# but couldn't?

    For example, do you think there would be value in a language that added a layer of abstraction between the syntax presented to a user, and the persisted form? Eg. if a language was stored on disk as an XML representation of the parse tree, then you could evolve the language (add keywords, etc.) and rely on the IDE tools to intelligent present the code to the user.

    I've been saving up this one for a while now.

    It's common for us to reject some features because they aren't along the lines of our language philosophy.

    It's also fairly common for us to reject a feature because we can't come up with a good syntax for the feature. Sometimes this is because we just don't like the constructs we come up with, because they are ugly, or they don't really make things simpler for the user, or they don't cover the right scenarios. The syntax we can use is heavily constrained by the existing structure of the language. Take a look at your keyboard, look at all the special characters, and tell me which ones aren't already used for something in C#. The list is very short, so we are constrained by the operators that are available. We're also constrained by whether our change would be breaking, and in what situations things would be breaking. C# 2.0 has no major breaking changes, and though that isn't an absolute rule for us, it's certainly a goal. Adding new keywords is, in general, a bad thing to do.

    Finally, we're constrained by what the runtime can/will implement, and whether things can be implemented across languages. Some features only make sense if they're done in all the languages, but that means all languages need to agree before we do it.

    Rick also asked about language evolution.

    There are different opinions about this. Some believe that languages should never change. Others believe that they should be able to extend their language at will. An extreme example of this is Intentional Programming.

    I think I'm one of the few people around who have actually played around with intentional programming. Conceptually, it's interesting, but in the real world, I think the “everybody designs their own language” approach is challenging at best. One can envision a world where the user representation is extensible but the underlying representation is standard, but I think that's a bad world to be in. It may be great for you, but it's probably not good for your team, or the poor guy who takes over your code two years from now. And there's a lot to be said for the “code in a text file“ world.

    We have well-defined ways for users to add functionality - through classes, methods, interfaces, etc. I think that languages should only consider adding features when there is an obvious shortcoming to solving the solution through existing functionality. At that point, you need to understand those issues and determine whether the language solution is the right way to address the issue.

    So I'm not big on extensible languages. Existing facilities - such as Macros in C++, do have their users, but are a disaster from the readability standpoint (both for the compiler and the developer).

  • Eric Gunnerson's Compendium

    Future language features & scenarios

    • 119 Comments

    We're starting to think about the release after Whidbey in the C# compiler team.

    I know that it seems strange that we have just shipped the Whidbey beta, and we're already talking about what comes next, but we're fairly close to being “shut down” for the compiler right now. So, we're taking the “big picture“ perspective.

    Since we're in this mode, now's the time to suggest things that we should add to the language and/or scenarios where you think the language falls short.

    An ideal comment would be something like:

    I'd like to be able to support mixin-style programming in C#

    If it isn't obvious what you're suggesting, please provide a link.

    It would also be good to suggest through code - something like:

    I currently am forced to write code like

    <ugly code here>

    and it's really ugly.

    I won't be able to respond to all comments nor will we implement all of them (or perhaps any of them), but we will consider all of them.

    Thanks 

     

  • Eric Gunnerson's Compendium

    Rescheduled C# Chat on TechEd topics

    • 1 Comments
    Our original chat got cancelled (don't ask...), and we've rescheduled it for this Thursday
  • Eric Gunnerson's Compendium

    Killing comment spam

    • 8 Comments
    Is there a .TEXT utility to let me kill all comments that have a specific URL in them? I've been getting hit with comment spam recently...
  • Eric Gunnerson's Compendium

    Why a manned space program?

    • 9 Comments

    One of the questions about in the comments to my post on Apollo question asked “Why do we have a manned space program?

    That's a fair question, but before I answer it, there are two things I want to talk about.

    The first is to give credit where credit is due. A tremendous amount of really good science has been done by unmanned probes, and with the exception of the moon, virtually all our knowledge about the solar system has come from these missions.

    The second is to be careful to define what we're discussing. When I talk about “a” manned program, I'm not necessaarily talking about the current manned program.

    So, why should we have a manned space program. Well, you should be sure to go read some of the information written by NSS, but here's my opinion:

    There is something about personal participation that fires the human imagination. Whether it's climbing Mt. Everest, travelling to the south pole, or flying higher than anybody else, people have always aspired to be the first to do something. Striving to accomplish that which is difficult is a defining human characteristic.

    So that's the abstract reason. But there are also practical reasons.

    The first reason is that space has the potential to provide nearly limitless resources. Whether it is possible to exploit them economically isn't yet clear, but if we could replace half of the world's coal-fired power plants with solar power satellites, we could make a tremendous reduction in the release of sulpher, radioactive elements, and greenhouse gasses. Clean power from space has a lot of appeal.

    There are also opportunities around other resources. If we could mine asteroid iron, our reliance on environmentally-damaging mining on Earth would be reduced.

    Given our continued population growth, the ability to spread out and get resources elsewhere is very interesting.

    The final reason concerns the long-term survival of the species. We have good evidence to global catastrophe in the past, and without spreading out to other planets, it's fairly certain that such an event will happen again.

    So, that's what I think, but those who are smarter and more informed than I am have written a lot on the subject.

  • Eric Gunnerson's Compendium

    35 years ago today...

    • 16 Comments

    35 years ago, two men came within 20 seconds of dying 250,000 miles away.

    Hours after averting tragedy, a very young Eric Gunnerson got to stay up late to watch Neil Armstrong walk on the moon.

    I was 5.

    I've always been a bit of a space nut, and my memory is full of important points in space history:

    • Armstrong and Aldrin's lunar landing
    • Apollo 13
    • Apollo Soyuz
    • Skylab
    • The first flight of Columbia
    • The last flight of Challenger
    • The last flight of Columbia

    But watching NASA the last 15 years makes me sad. Despite some good efforts to reform the culture and get back to the kind of organization that recovered from Apollo 1, NASA has not suceeded in reforming itself, and it's stuck with a hugely expensive shuttle and a space station without a clearly-defined purpose. The unmanned and astronomy programs continue to be excellent, but manned spaceflight has lost it's way.

    At this point, I think you'd get a better result if you cancelled two shuttle flights and gave Burt Rutan and Lockheed Skunkworks the money for one flight, and let them work to advance the state of the art.

    But having said that, I would like commemorate the dedication and sacrifice of all those involved in Apollo. Many sacrificed money and their family relationships to the cause. Some gave their lives. Gus Grissom, Ed White, and Roger Chaffee died in the Apollo 1 fire. Charles Bassett, Theodore Freeman, Elliot See, and Clifton Williams died in training mission plane crashes.

    Here's hoping that this is not the last time that humans will walk on other worlds.

  • Eric Gunnerson's Compendium

    Naming generic type parameters...

    • 31 Comments

    There's been quite a discussion going on on the MSDN feedback site over the naming of generic type parameters.

    If you look at the definition of the generic collections classes, you'll see things like:

    List<T>
    Dictionary<K, V>

    What's up with those T's, K's, and V's?

    If you look at our beta1 library design guidelines (can't find a published link right now) that suggests that you use single-character names for type parameters rather than longer, more descriptive names. But those guidelines weren't always there. In fact, before we had them, you might see a class like:

    class Dictionary<Key, Value>
    {}

    which seems reasonable enough. But one day, you're browsing code, and you look at a method:

    public void Process(Key k)
    {
        // code here...
    }

    What's Key? It looks like it's a type, and unless you know that there's a type parameter named “Key“, you're likely to be confused for a while. We therefore decided to use the single-character naming approach, and my experience is that it's worked pretty well.

    When you're working on a generic class, you normally have a small number of generic type parameters, and therefore it's not that hard to keep them straight. When you're using them, C# intellisense is nice enough to give you a description for the type parameter so you remember what it is.

    That is, it's nice enough to do that if you remember to *write* the description using the <typeparam> tag. The IDE will add this tag automatically when you type the /// before your generic class definition.

    Unfortunately, the beta1 drop doesn't have these descriptions for the built-in collection classes, so you don't get any help right now if you type “List<“. We'll be fixing that.

  • Eric Gunnerson's Compendium

    Alfred is worried...

    • 10 Comments

    Those of you who read my holiday letter post from last year may remember that Alfred is my Roomba. That is, if you haven't blotted the experience of reading the post out of your mind.

    See, I warned you, and what did you do - you went back and looked at the post anyway. Isn't the picture of Alfred wearing the basket cute?

    Roomba has been a loyal servant for these past months, and except for occaisional bouts of catatonic paralysis at the edge of our stairs, has performed his duties with devotion an diligence.

    But there's a new kid in town:

     

    Roomba discovery is here:

    New features are:

    • Bigger bin
    • Better battery
    • Self-charging (roomba finds his charger on the floor)
    • Dirt detection
    • Automatic hat wearing
    • Enhanced “sulk“ mode
    • Teenager mode (cleans while you watch, then goes and watches TV when you leave)

     

  • Eric Gunnerson's Compendium

    Google is my personal search engine

    • 7 Comments

    Google gives high weight to blogs. In fact, google gives too much weight to blogs. Too often I've gone to research something that I only know a little about (say, training for a century) and found that my post is on the first page of results. Want to know what it's like to turn 28? I'm apparently the expert.

    It does have its uses, however. Today I needed to find an old blog post, and I found that if I type:

    eric <word> <word>

    more often than not, the first hit is my blog post. Convenient.

    Of course, it may be that Google is doing this to protect me from the “Total Perspective Vortex

     

     

     

     

     

  • Eric Gunnerson's Compendium

    Fixed statement and null input...

    • 17 Comments

    I'd like some input on a change we're considering for Whidbey.

    Consider the following wrapper class:

    unsafe class Wrapper
    {
        public void ManagedFunc(byte[] data)
        {
            fixed (byte* pData = data)
            {
                UnmanagedFunc(pData);
            }
        }     void UnmanagedFunc(byte* pData)
            } }

    In this class, I've fixed a byte[] array so I can pass it to an unmanaged method. I've included “UnmanagedFunc()“ in my program to illustrate what it looks like, but I would normally be calling a C function through P/Invoke in this scenario.

    The problem with this code is that some C APIs accept null values as arguments. It would be nice to be able to pass a null byte[] and have that translate to a null pointer, but the fixed statement throws if it gets a null array.

    There's an obvious workaround:

     public void ManagedFuncOption1(byte[] data)
     {
       if (data == null)
      {
        UnmanagedFunc(null);
      }
      else
      {
       fixed (byte* pData = data)
         {
         UnmanagedFunc(pData);
       }
       }
     }

    and a less obvious one.

    public void ManagedFuncOption2(byte[] data)
    {
     bool nullData = data == null;   fixed (byte* pTemp = nullData ? new byte[1] : data)
       {
       byte* pData = nullData ? null : pTemp;
       UnmanagedFunc(pData);
      }
    }

    Thr problem with the workarounds is that they are ugly, and they get fairly complicated if there is more than one parameter involved.

    The language spec (section 18.6) says that the behavior of fixed is implementation defined if the array expression is null, so we could change our behavior so that fixing a null array would result in a null pointer rather than an exception. 

    Questions:

    1. Have you written code where this would be useful?
    2. Are there situations where the change of behavior would cause you problems?
    3. Are the workarounds simple enough that this isn't an issue?

     

  • Eric Gunnerson's Compendium

    Microsoft & Java communities...

    • 2 Comments

    TheServerSide.Com has a post up that references what Don Box and I wrote, and there are some comments that you might find interesting. And not just because of the nice things that Rolf said about me.

    I agree with Cameron when he says:

    The difference in the Java market is that the community is made up of peers. It is _not_ simply a vendor / customer relationship of convenience.

    This was what I was trying to get across in my summary post around JavaOne. Though we've made some good progress in the community space, we're still not very open from the design side of things, and that's a challenge we should take on.

  • Eric Gunnerson's Compendium

    Decreased performance when compiling with no options...

    • 12 Comments

    One of the things that we've done in Whidbey is add some extra IL instructions to improve the debugging experience. This allows you to (for example) set a break on a closing brace.

    Because /o- is the default setting, this means that performance if you just compile with “csc” will be slightly degraded in Whidbey. If you've been building without setting /o+ and you care about perf, you will want to change your code to throw /o+ explicitly.

    If you're using VS release and debug configurations, this will be set automatically for you.

     

  • Eric Gunnerson's Compendium

    Le Tour

    • 14 Comments

    This week starts part of my favorite part of the summer, “Le Tour de France”. The tour is likely the hardest athletic challenge in the world. Last year, Armstrong covered 2100 miles at an average speed of just under 26 MPH, including 7 days of riding over mountain passes.

    The best TV coverage is on OLN, though you need to get past the whole “Cyclism” thing. I recommend recording the early morning live broadcast, as they use different commentators for the afternoon recap.

Page 1 of 2 (31 items) 12