June, 2004

Posts
  • Eric Gunnerson's Compendium

    Close one chapter. Open another?

    • 16 Comments

    A few days ago, I said that I was considering a big decision (for me) that would simplify my life.

    After a bit of discussion, my wife and I have decided that we're going to sell our motorcycles (though we may replace them with off-road bikes). This is a somewhat painful thing to do.

    Let me explain.

    Way back in college, I drove a 1968 Citroen Safari station wagon. Citroens have a very interesting hydraulic suspension that is unsurpassed in ride quality. They do have a few drawbacks.

    First of all, Citroen is not known for their horsepower, with the exception of the Maserati-engined SM.

    The second is that they tend to have timing chain problems when they get high mileage. The timing chain runs from the crankshaft to the camshaft, and opens and closes the valves. At least it does until it breaks, at which time the pistons come up, whack the valves, break them, and then proceed to embed the valves in the tops of the pistons. All the while making a most horrific sound.

    So, there I was in my senior year, and I need a mode of transportation, and I had $800 I could allocate to the effort. That would either buy me a pretty poor car, or a halfway decent motorcycle, so I soon had a Honda FT500, and was commutting on it.

    That led to a bit over a decade of commutting almost every day (even through some snow), riding somewhere around 80,000 miles, and teaching a fair number of classes for the Motorcycle Safety Foundation (if you're thinking of riding, make sure you start there). I upgraded bikes twice for me and twice for my wife, and we used to spend a fair amount of time riding.

    Then, we bought a house in Bellevue, and commutting by bike no longer made sense. I still rode occaisionally, but over time I've gotten more busy, and the bike hasn't been out of the garage since last October.

    It's sad. I still really, really enjoy riding - the power to weight ratio is far better than nearly all cars (at least those I could justify buying), but it's something that you need to do often to be proficient, and I just don't have time these days. Or, to put it differently, there are lots of things that rank higher right now, and we're paying for both depreciation and insurance on both bikes.

    So, I put ads for a 1997 Honda VFR750 and a rare 1994 Honda CBR400RR Japanese home market spec in the MicroNews.

  • Eric Gunnerson's Compendium

    The Lunar Men

    • 7 Comments

    The time: The early 1700s
    The place: England, at the beginning of the Industrial Revolution.

    In this book, Jenny Uglow details the lives of the group of men - industrialists, scientists, doctors, and others - who made up the “Lunar Society of Birmingham“.

    Some of them you've may have heard of - James Watt, Joseph Priestly, Erasmus Darwin. For others, such as Josiah Wedgewood, you may know the name from something else .

    And other you've probably never heard of.

    This is a pretty good book. It's interesting, for example, to find out about the amount of chemistry that is required in pottery making to get the right result.

    It would be a better book, however, if it were around 300 pages rather than 500 page in length. There's a lot of detail there, and while I appreciate a desire for historical accuracy, after 400 pages I lost interest and moved on.

  • Eric Gunnerson's Compendium

    The W in Seattle

    • 8 Comments

    Last night, my wife surprised me with a night at the W in downtown Seattle as a late birthday present.

    The W is currently my favorite hotel by far. I spent a little time last night thinking about why.

    It's not because they have a “living room” rather than a lounge.

    It's not because there's house (or trance (or drum and base (or something like that))) music playing in the elevators.

    It's not because the rooms have really clean design.

    It's because the experience is consistent. Somebody took the time to think about the whole hotel experience, and make it as smooth as possible. Even down the “do I want the sheets washed” sign, which is a wheel that lets you set it to whatever you want.

    I appreciate that level of thought.

    We had dinner at Cutters, a great place for seafood.

    This morning after breakfast we walked over to the new Seattle Library. Nice building, but the neon green is too jarring.

     

     

     

  • Eric Gunnerson's Compendium

    Life Simplification

    • 19 Comments

    A good friend of mine recently resurfaced after being out of touch for about 18 months. The last time I had lunch with him, he was having some marital issues and had just joined the ranks of the unemployed (he's a tech guy as well).

    In the 18 months, he got divorced, took some Spanish classes, and then went on a home-study trip to Costa Rica. When he got back, he decided he needed a different kind of job, so he's now working as a ramp service agent for Alaska Airlines at SeaTac airport, and looking to get back into writing.

    I envy his ability to push the reset button on his life, and then figure out what he really wants to do when he grows up.

    I've been trying to simplify my life as well recently, though I doubt that any changes I make will be as drastic as his were.

    The tradeoff between money and free time is a hard one. Ideally, I'd like to have both, and while that could happen if my stock market investments go well, it's not something that's going to happen overnight - or even in the next few years.

    I may write about one specific “life simplification” decision in a separate blog, if I decide to go that way...

  • Eric Gunnerson's Compendium

    Strangely Compelling

    • 3 Comments

    I'm thinking of setting up a new category named “Strangely Compelling”.

    I came across a link from the Journal of Improbable Research (also home for the Luxuriant Flowing Hair Club for Scientists (LFHCfS)), which led me to the following pictures:

    Want to try your hand?

    Visit Warp-A-Kitty

  • Eric Gunnerson's Compendium

    How an idea becomes a C# language feature?

    • 29 Comments

    In a recent email, a customer asked for a delegation feature. He wanted to do something like (purely theoretical syntax):

    class MyClass: ITest
    {
        MyHelperObject o: ITest;
    }

    so that he could delegate the implementation of the interface to a helper object, and have the compiler automatically generate the interface implementation methods.

    My response was that we had talked about this several times in the past, but hadn't been able to come up with a syntax that worked well.

    This is a not uncommon state for us - on several occasions in the Whidbey (excuse me - “Visual Studio 2005”) design process, we tried to come up with a syntax that allowed the user to declare a trivial property (backing store, trival getter and setter) with one bit of syntax, but weren't successfull.

    I thought I'd talk about that process to give you some insight on how we approach things. I can't be exhaustive with all of our considerations, mostly because we don't really operate that way (there isn't a set checklist). If you have a question on a specific feature, I am happy to consider talking about other features and decisions - see the “suggest a topic” hard link on my main page. Just note that my success rate on actually covering such topics is not exemplary. Also note that I make no attempt to answer questions in the order asked.

    The process is fairly organic, in that the steps I list don't happen sequentially, and they are often iterative. Despite the length of this post, I've simplified what goes on significantly.

    Sniff Test

    We start with what I'm going to call the “Sniff Test“, which is basically the highest level triage to determine if we think such a feature is something we would ever consider for C#.  Some features fail because they don't fit the language philosophy, some fail because there's no way we could ever express them in syntax.

    Scenario Exploration

    Our next level of attack is looking at what user problem we're trying to solve. This typically involves us writing down (or up, on the whiteboard) the code that users are currently writing. Sometimes this is limited to the most common scenario, sometimes we'll cover several scenarios - it all depends on what we need to know. This often happens iteratively with the next step.

    Syntax Iteration

    If we've gotten to this step, we're usually fairly convinced that there is a user need. We don't yet know if there is a language solution to that need. In this step, we'll start talking about what we could do in the language to make the developer's life easier.

    This step typically works with Anders writing on the whiteboard while the rest of the design group gives suggestions and feedback. When we hit on a promising approach, we'll explore it for a bit to see where it leads us, contrast it to other approaches we could take.

    In this step, we're asking questions such as:

    • Does this new syntax cover the important scenarios?
    • Does it really make the user's life easier? (new syntax is not a panacea - each new feature adds complexity)
    • Is this syntax unambiguous? Is it possible for the parser to correctly deal with this new feature in the presence of all existing features? (this is a very limiting area)
    • Would this be a breaking change for existing users? (Adding new keywords are examples of breaking changes, but it's also common for new language ambiguities and/or differences in behavior to show up because of new features)
    • Does this feature fit the philosophy of the language?
    • How will this impact tools? Can IntelliSense deal with this?
    • Is this a language feature, or would it be better done through an API, or through the IDE?
    • How have other languages approached this? Has their approach been successful?
    • Does this require new features in the runtime?
    • Does this require work in by other languages?
    • What Microsoft teams would use this? Are they on board to use it?

    In a single session, we will sometimes decide to do a feature and sometimes decide to not do a feature, but more typically we'll decide that we need to discuss it more. We go away and think about it, gather feedback from the people who read our language notes and those closest to the scenario, and then revisit it in a future meeting. A lot of the iteration is around exploring all the corner cases (some of which don't come up until implementation) and making sure the feature is well defined, still does what we want it to do, and still is in the best interests of the developer.

    It's not uncommon for us to change our minds on the details of a feature, or even to decide upon reflection that we need to either reduce or eliminate a feature.

    Structured Feedback

    If we've gotten to this point, we're fairly sure that we want to have the feature, and typically have an implementation (though not always). We use feedback with the C# Customer Council (a small group of customers who we work closely with), and the C# MVPs (we've done a little with the MVPs in the past, we'll be doing more in the future) to see what their perspective is on the feature.

    This is also the point where we work with the ECMA standards body to talk about our proposal, though it's often difficult to align the schedules of the standards body with product milestones.

    There may also be internal Microsoft presentations at this point, depending on the feature.

    Many times the feedback is positive, but sometimes it causes us to refocus the feature, and there have been language features that we cut due to feedback at this point.

    Manufacturing and Shipping

    If we've gotten this far, the feature is in the language, and often implemented. The remainder of the work is to polish the implementation, finish the testing (sometimes testing is concurent with implementation, sometimes it lags a bit - it depends on the type of feature and our resource constraints), do the spec, and discuss how we'll be presenting it to customers.

  • Eric Gunnerson's Compendium

    Java Developer Resource Center

    • 2 Comments
    There's a new resource center for Java users who want to interop, evaluate, or migrate to the .NET Framework.
  • Eric Gunnerson's Compendium

    DEV 322 Visual Studio 2005 C# IDE Enhancements - Walkthrough available!

    • 0 Comments
    Joe did a great job with this presentation, and he's now posted his walkthrough. If you want to understand what's coming up in the next release, take a look.
  • Eric Gunnerson's Compendium

    Visual Studio Breakpoint Helper

    • 1 Comments

    Visual Studio Breakpoint Helper

  • Eric Gunnerson's Compendium

    .NET Framework Bootstrapper

    • 1 Comments

    The .NET Frameowrk Bootstrapper makes it easy (er) to distribute the framework as part of your application. (yes, that is the right post - look at the bottom).

     

  • Eric Gunnerson's Compendium

    Math.NET

    • 3 Comments

    I came across this on one of our internal aliases.

    Math.NET is a cool mathematical framework. It supports both arithmetic and symbolic operations.

     

     

  • Eric Gunnerson's Compendium

    The Difficulties of Language Design

    • 6 Comments

    Phil Haack writes about the difficulties of language design.

    And no, I'm not linking just because he mentions me twice...

     

  • Eric Gunnerson's Compendium

    Nullable type support in the community preview

    • 5 Comments

    One reader commented that nullable types don't seem to fully work in the community preview drop.

    He's correct, and I apologize for not making that clearer in my post.

    The time constraints of the community preview prevented us from getting all the nullable support in the compiler, but it will be there in the upcoming beta.

    For the community preview, the following things work:

    • You can write a nullable type using the “?“ syntax
    • There are conversions from T to T?
    • You can use HasValue and Value on the type.

    The following things don't work:

    • Adding two nullable ints together (or any other operations that operate on the underlying type)
    • Comparing a nullable instance to the literal “null“
    • Using the ?? operator
    • Converting from S? to T? if a conversion from S to T exists.
Page 2 of 2 (38 items) 12