[Blog Map] This blog is inactive. New blog: EricWhite.com/blog
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.
It 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.
It's interesting how many comments along the lines of "LINQ is great, but we don't bother with SQLish syntax" are there already. It confirms something I've suspected before - the people who most appreciate LINQ are those with previous FP background (if only theoretical), and they find the plain chained function calls with lambdas more to the point.
Even though we are a MS-shop, I'm not comfortable in recommending DLINQ to my team until it supports (at least) Oracle databases. I rather work our system towards multi-database support than include yet another proprietary layer.
Just a quick response to the topic. We use Lambda expressions and LINQ extremely regularly in our shipping product for an international shipping and forwarding company. We use NHibernate for our data access, but I have another company for whom I do work and we use LINQ to SQL for that product.
If I may recommend looking into the dependency injection and "interfacing" your DAO layer such that you can avoid the issues you are concerned about. Even if DLINQ supported Oracle from day 1 and you used it, you've still bound yourself tightly to a technology stack... the DLINQ technology stack.
I'm using LINQ with the ADO.NET Entity framework.
it's very effective.
Started using LINQ to SQL , LINQ to XML & LINQ to Objects .. extensively .. and we never regret it !
But looking forward to C#4 and the next iteration for LINQ .. perhaps with a better support for n-tier applications ..
int19h > "the people who most appreciate LINQ are those with previous FP background (if only theoretical), and they find the plain chained function calls with lambdas more to the point."
Query comprehensions are very useful in some scenarios, mainly because C# doesn't have tuples. But yes, in general, I dislike the "SQL" syntax and don't agree with renaming functions to make it easier for people who only know SQL.
We do not use link.
We are not fully on 3.5 yet, and our DBA does not want it.
> "our DBA does not want it"
What does that mean? LINQ is not about databases. LINQ to SQL and LINQ to Entities are.
If you don't consider using LINQ to Objects and LINQ to XML, then you're missing what makes LINQ important.
A couple disappointments:
- people write "link" when, after 3 years, they've had time to learn "linq"
- some respondants think that linq doesn't exist outside of linq to sql ("our DBA does not want it".. this should prevent people from querying in-memory collections, Active Directory, or anything else?)
- some think that linq to sql is the only rdbms provider for linq
I've been using LINQ since, pretty much every day since Jan 2006 (benefits of development compilers). I've been teaching it to coworkers as needed, and my background doesn't include a degree in CS or any particular experience with FP (F# syntax and I don't mesh well, FWIW).
In LINQ's case, I just "get it", which IMHO is true of most technology. You either do (and therefore experience a quick learning cycle) or don't (and just get cranky about it).
Unfortunately, not a lot of programmers were exposed to FoxPro. For FoxPro programmer all this LINQ is old news. MS killed VFP, but took some it's good features to .Net.
We're using LINQ on all new development. It takes a little getting used to, but is intuitive, powerful and productive once you get it.
I have been using LINQ for about a year now on two projects and could never go back to the old SQL string approach in ADO.NET. But it hasn't gotten a lot of interest at my company since there are lots of developers entrenched in legacy apps.
> Unfortunately, not a lot of programmers were exposed to FoxPro. For FoxPro programmer all this LINQ is old news.
FoxPro allowed you to query objects and XML in memory, and to write extensible query providers?
If you think that LINQ is just about having the query language as a part of the host language, you miss the point (though the very term "language-integrated query" makes it easy to do so). The really interesting bits of LINQ are lambdas, expression trees, and the new libraries that use all that, not the syntactic sugar for it all.
I have recently started to use LINQ because of ASP.NET MVC. So far I have only used it with stored procedures because in my company we never worked with direct sql queries in code. I can't take out any conclusion for now but so far I liked it.
I'd really like to hear more from folks who haven't started using it yet. There are legitimate reasons - some companies haven't moved to VS2008 yet, for instance.
I've summarized some of my thoughts about the responses to this post at http://blogs.msdn.com/ericwhite/archive/2008/07/26/are-developers-using-linq-part-2.aspx.