title: Should I not use LINQ to objects because Microsoft might change it?
body: <p>I got into an argument with a co-worker about the use of LINQ to Objects (IEnumerable, not IQueryable) in our C# code.  I was using LINQ, and he said that we shouldn't be using an external vendor's (Microsoft) code in our code, but that we should wrap it ourselves in our own layer of abstraction.</p>
  
  <p>Now I understand this methodology for use where you've got a no-name third party dll that may go out of business next week, or when your dealing with database calls (ie. returning a common data provider, rather than a SQL or Oracle specific one), but in my mind the LINQ syntax is too pretty/elegant/readable for Microsoft to abandon in the next 10 years.  It's about as likely to be dropped as the ToString("Hello {0}", firstName); functionality.</p>
  
  <p>I could give up arguing, and implement our own LINQ library that calls the standard LINQ methods under the covers, but isn't this over doing it?  Plus I could only use the extension methods, I have no idea how to be able to wrap this: </p>
  
  <pre><code>from e in employees
  select new { e.Name, e.Id };
  </code></pre>
  
  <p>What would your argument be, for or against using LINQ to objects (the IEnumerable extension methods)?</p>