Immo Landwerth

• Immo Landwerth and Andrew Arnott: Inside Immutable Collections

  Mar 20, 2013 at 11:51 AM

  10 hours ago, felix9 wrote

  If the MSR work you talked about is this
  http://research.microsoft.com/apps/pubs/default.aspx?id=170528

  Yes, I believe that's the paper we referred to during the interview.

  I like language innovation a lot but things that affect the type subsystem in such a fundamental way are very hard to incorporate into an existing language like C#. It seems impossible to this on "on the side" as immutability is quite sticky; meaning you those sort of constraints need to be propagated around in the entire system to be beneficial.

  Also, applying this to the hundreds of thousands of APIs in the .NET FX might be prohibitively expensive...

• Immo Landwerth and Andrew Arnott: Inside Immutable Collections

  Mar 19, 2013 at 7:22 PM

  Hi Marcus,

  That's a lot of interesting questions! Let me take them one by one.

  3 hours ago

  Why not allow user to select implementation using a factory function? The allocator most often knows how the collection will be used. For example that indexer or add must be O(1). The current AVL solution doesn't sound too good for paging and slicing. How would I create a slice of an ImmutableList? Did you look at Dlang ranges?

  I haven't looked at Dlang ranges -- Andrew might have more context there. In general, we are not convinced that offering a knob for every option is the right thing. In the end, our goal is delivering a list of collection types that work for a wide variety while still being easy to use and agree upon. The Roslyn use case we brought up is quite special -- Roslyn has super tight perf constraints that most developers will not have. Once you are in this boat, chances are you want to have more control than what we can realistically offer in the BCL.

  For those case we still offer the immutable interfaces as the exchange currency.

  And .ToList() is commonly used on IEnumerables to materialize them from linq or other enums to make sure they are O(1) indexed. Not only to get a safe copy to foreach over. Will you add a ToImmutableList()? And will that be a noop if the IEnumerable is already an ImmList?

  Our library offers an extension method for IEnumerable<T> that provides ToImmutableList().

  If you call ToImmutableList() on an immutable list, you will get back the same instance, assuming it uses the default comparer. If it doesn't we change the comparer. In any case, that's an O(1) operation.

  Is that what you are looking for?

  An immutable list where add/indexer is O(1) with an array backing store would be nice. The allocation time would be amortized. The extra space created in array realloc could be used for non concurrent adds or adds in creator thread.

  We still entertain the idea of ImmutableArray<T>. The type would be a struct wrapper around an array. Constructing would copy the array once to avoid anybody can violate the immutability guarantee. Indexer would be O(1). However, we wouldn't support persistent operations. In other words, adding or changing items would not be supported.

• Channel 9 turns 9!

  Mar 15, 2013 at 8:00 AM

  Happy Birthday! You guys are the reason I decided to join the dark side

  Hope there are at least nine more years to come.

• Erik Meijer, Immo Landwerth, and Andrew Arnott: Immutable Collections for .NET

  Jan 20, 2013 at 2:18 PM

  13 hours ago

  Nice addition! But I wonder for how long they will be relevant? In Win8 apps! where HTML5, Javascript and C++ are first class citizens and .NET has been demoted to second class citizen?

  First of all I don't think that's true. I was the PM driving the .NET surface area you can use when targeting Windows 8 store apps. Let me tell you: the entire .NET Framework team and large chunks of Visual Studio spend significant amount of resources to make this an awesome experience. As with every technology that is advanced enough by adding a non-trivial set of features, there are rough edges and I'm the first to admit that. However, the same is true for C++ and JavaScript given that Windows Store apps run in a different environment that are new for them, too. We all try very hard to make writing Windows Store apps as easy and smooth an experience as possible.

  Secondly, looking back to the days when Microsoft announced .NET, I think we've learned from that in the sense that we no longer promote a single technology to rule them all. We've made the mistake with .NET which lead to unrealistic expectations what .NET would deliver. I believe the .NET platform is the most productive development platform out there (otherwise I wouldn't work here) but I also believe it's not for everybody. Different tasks require different tools. And someone needs to write the CLR as well

  Rest assured that .NET isn't going away any time soon. You don't need to take my word for it -- just think of all the products Microsoft offers that are written in managed code.

  For platforms like Windows the key is offering choice. Some might have a strong web background with JavaScript. Others come from the native world and prefer C/C++. Others are .NET developers.

  My advice: ignore marketing and choose what you feel comfortable with and what gets the job done best.

• Erik Meijer, Immo Landwerth, and Andrew Arnott: Immutable Collections for .NET

  Jan 20, 2013 at 1:55 PM

  9 hours ago

  The BCL blog post http://blogs.msdn.com/b/bclteam/archive/2012/12/18/preview-of-immutable-collections-released-on-nuget.aspx suggests that the release of NUGet package is for .NET Framework 4.5 but during installation I stumbled upon following issue,
  
  Successfully installed 'Microsoft.Bcl.Immutable 1.0.5-beta'.
  Successfully uninstalled 'Validation 2.0.1.12362'.
  Install failed. Rolling back...
  Install-Package : Could not install package 'Validation 2.0.1.12362'. You are trying to install this package into a project that
  targets '.NETFramework,Version=v4.5', but the package does not contain any assembly references that are compatible with that
  framework. For more information, contact the package author.
  ...
  
  Any idea what am I doing wrong please?

   

  Yes -- you are using a NuGet 2.0. Make sure you've updated to NuGet 2.1 or higher. Just open VS and go to Extras | Extensions and Updates | Updates. There is probably a NuGet 2.2 knocking on your door

• Erik Meijer, Immo Landwerth, and Andrew Arnott: Immutable Collections for .NET

  Jan 17, 2013 at 10:15 PM

  @al3891: You're right -- the example I gave in the video is busted. In fact, Erik caught me on this during the interview but he was kind enough not calling it out

  The C# compiler is able to resolve the overload because T is more specific than IEnumerable<T>. In other words, the compiler favors identity conversions over any implicit conversions. Theoretically you could envision that other compilers might handle this differently, but I kinda doubt that;s a realistic assumption.

  However, it's possible to construct ambiguous cases:

  class MyList<T>
  {
      public void Add(T item) {}
      public void Add(IEnumerable<T> item) {}
  }
  class Base {}
  class Derived : Base, IEnumerable<Base>
  {
      public IEnumerator<Base> GetEnumerator()
      {
          return null;
      }
      IEnumerator IEnumerable.GetEnumerator()
      {
          return GetEnumerator();
      }
  }
  var list = new MyList<Base>();
  list.Add(new Derived());
  

  Now is that a big deal? Probably not because you can resolve this conflict easily using a cast and it's not a very common scenario.

  Well, why are we following the existing naming convention then? Because it's an existing naming convention. If you can do (A) or (B) but (A) is already established we favor (A) unless (B) offers a significant improvement. In this case I don't think it does.

• Erik Meijer, Immo Landwerth, and Andrew Arnott: Immutable Collections for .NET

  Jan 16, 2013 at 1:39 PM

  @Jarred: Yep, that's a common mistake when starting to use these new collections 

  @mdonatas: In fact that thank goes straight to Andrew Arnott - he wrote the immutable collections that Roslyn uses. However, you are right from the perspective that Roslyn definitely created a need for bringing a common way to represent immutable collections to the BCL.

• TWC9: GenerationApp, Windows 8 UX, New in ASP.NET Testing WinJS and Pixies

  Aug 25, 2012 at 10:17 AM

  "This is my last show" -- Your serious face definitely got me

• TWC9: Build sold out, Portable Class Library, eBooks galore, SQLite, WinRT and more

  Aug 11, 2012 at 9:43 AM

  Just to clarify: you cannot access .NET 4.5 only APIs from a WinRT component (AKA WinMD). Using Visual Studio, such a project will compile against .NET Core, which is the same set of APIs that ordinary Windows Store app .NET class libraries will use. Even if you manage to compile that WinMD yourself, the store will catch any dependencies outside of .NET Core and reject the app at submission time.

  However, the ZIP APIs in System.IO.Compression can be wrapped in a WinMD because it's available in .NET Core.

• TWC9: SQL Server 2012, VS11, Win8 Metro, Bing Maps Metro and more

  Mar 12, 2012 at 9:28 AM

  Great to see Charles in front of the camera again. That has become way too rare.

  More Air Rubik Cubes

See more comments…