I had an interesting conversation with my nephew the other day. He is a very bright CS student working as a summer intern at a software company (not Microsoft). He is programming in C# using Visual Studio 2008. I asked him if developers at his company were using LINQ, and he said, "No, that the folks in charge had basically forbidden it, because no one understands it." Visual Studio 2008 has been out for over nearly a year, but I know that a fair number of competent developers have not devoted the time and effort to learn about the style of programming that LINQ enables.
This blog is inactive.New blog: EricWhite.com/blogBlog TOCIt IS worth it to spend the time to learn about LINQ. From comments I have received, I know that it takes only about eight to sixteen hours to work through my Functional Programming Tutorial. This is a far smaller effort than even a single CS course at a university. I know that I have saved that amount of time many times over in the last two years. I write programs faster, and they work more reliably. I have another blog post in mind that details exactly why programs written using LINQ have fewer bugs. I'll get to it pretty soon.
From the conversations I've had, I also know that there are a fair number who do get it. I receive comments from "typical" object-oriented developers who have read my Functional Programming tutorial, and have made the transition to the functional style of coding. While it is a bit of a transition to think about programming in terms of transformations instead of algorithms, it isn't a difficult concept. I think that this is analogous to the transition that we all made (if you are old, like me) to object oriented programming in the mid 80s.
It is possible to make the transition; I did so. And there is a high return on investment for the time spent. If you haven't done so yet, carve out a weekend, and work through the tutorial.
Some of the developers that I've spoken to have said that the functional programming course that they had to take when getting their CS degree was their least favorite course. They felt that the concepts were difficult to understand, and they had to write using a syntax that they felt was strange. Functional programming using C# 3.0 is a whole different animal from more "traditional" functional languages, such as Lisp, Haskell, Erlang, or Ocaml. It really is much easier using C#. The only really new syntax in C# is that of lambda expressions.
I'd like to take an informal poll about this. Do developers at your company understand and use LINQ? Do you? Can you see the benefit? Please leave a comment on this post, and let me (and others) know about the use of LINQ in your development efforts.
LINQ had definitely been a great addition to the toolbox. I've always detested writing SQL code and having the compile time checking of query code makes life better.
Personally, I found the learning curve shallow, but I agree with those who say that a CS background helps in grokking this quickly.
Being picky here, but "Visual Studio 2008 has been out for over a year" is not true. It was released 8 months ago. Betas don't count in the "enterprise" world. Even the final product will take time before it gets adopted.
Regarding LINQ and the learning curve, I think that there are several good books around that can really help to get people started ;-)
I used LINQ to XML. However I don't use LINQ to query databases. I use coolstorage.net. LINQ as a data mapper just isn't quite good enough yet.
If I didn't already have a very good ORM solution, LINQ would be much more appealing. As is, it's a great DOM/XPath replacement.
I'm using LINQ extensively to execute queries on in-memory data sets. It took me next to no time to learn, once I got my head around what the types were doing.
It's disappointing that you can't really debug a LINQ statement. To a first approximation, it either works or it doesn't, and if it doesn't, you have to figure out why without being able to examine any of the internals. It's also annoying that LINQ breaks edit-and-continue. Both of those make it feel like it's not fully cooked.
Getting good at Python has greatly expanded the kind of code I can write in C#, but that has only a little to do with LINQ. (Sadly, after you learn Python, the exciting shiny world of Reflection becomes a dismal dusty backwater made almost completely out of fail.)
We use LINQ (to objects) constantly. I'd say 95% of the usage across the team is via extension methods, query syntax never really caught on.
People seem to grok the value pretty quickly, but there is certainly a learning curve for new developers.
Code reviews are a good tool for helping people new to LINQ identify places in code where it offers a useful abstraction.
I find it's easier to convince people to use `Select' and `Any' than `Aggregate' or even `SelectMany'.
I started using LINQ to XML during beta and fell in love with it. No more verbose, heavy serialization classes, no more ugly XPath.
Later I tried LINQ to SQL for a project and it worked well enough.
More recently, I use LINQ to Objects almost always now (if applicable). And LINQ to XML if dealing with XML. I would probably try using LINQ to SQL again if I had the need...
I start LINQ soon as Scott Guthrie started to blog about it. From that day on I haven't look back. LINQ is awesome.
I've been using it for personal projects since Orcas went gold, but unfortunately haven't had the opportunity to use it for any client work.
Most of the work I do is maintenance (unfortunately), and when clients are paying by the hour, changing tested and stable codebases to use a different data access strategy (with no visible difference to the user) does not provide many tangible benefits.
I use it and most others look in awe. I'm working on setting the situation straight, though :)
I've worked with C# 3 at three companies. One had a skeptical boss (I believe his comment was "you're not using lambdas"), but the developers were quick and we got to use a lot of the C# 3 features. Between anonymous methods and the handy Enumerable methods, we cut out around 2000 lines off the codebase.
At another company, some members got FP and thought it was great, but we had strong resistance from some people who were simply unable to wrap their head around it. In particular, generics and expression trees were too much.
Now on my own project, everyone is quite functionally fluent and it's given us a huge advantage. For instance, we were able to add some simple, useful extensibility by parsing strings into Expression<T> then inspecting, manipulating, and compiling them at runtime.
Although, C# doesn't go far enough and is quite annoying when you want to write functionally or generically. So as soon as the "official" F# product comes out, we're planning on moving a lot of development over.
Yeah, everyone on my team has been using linq for almost a year now and it has made its way deep into our code base.
We're using it and loving it. It took our team 2-3 weeks to really get it, and the power of the technology keeps revealing more of itself over time. Having a general and abstracted query mechanism over multiple data sources (in memory, database, XML, etc) is just fantastic. No less fantastic is the usefulness of the underpinnings - lambdas, extension methods, etc. What great productivity enhancers!
Eric White has written an interesting post titled "Are developers using LINQ?" - there are interesting
We're using it in new code since the early days of Visual Studio 2008. None of us has a Background in functional programming but we first use it in prototypes and test programs, mainly for managing objects. And now you see more and more storage layers based on LINQ. Especially that every dataaccess uses nearly the same syntax and has a lot of power at your fingertips pleases most of us.