Are Developers Using LINQ?
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/blog
Blog 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.
Comments
Anonymous
July 23, 2008
PingBack from http://blog.a-foton.ru/2008/07/are-developers-using-linq/Anonymous
July 23, 2008
In the last 6 months, our developers have started using LINQ. Although there is an initial learning curve it is a lot less steep than we expected - people take about a week to get into the basics, and a month to get to the point where they understand more deeply. However, it is worth saying that those with a stronger CS background take to it faster; if you've spent any time with ML or Haskell or whatever, at any time in the past, it all comes flooding back. People who came from other engineering disciplines have some "fundamentals" to learn first.Anonymous
July 23, 2008
We are using LINQ in our projects. O/R mapping is done by NHibernate as it is mature product and we know how it works. But all local collection queries are done using LINQ. There is one human-factor based problem with LINQ. If somebody writes repository method that returns large list of objects then there may be hard performance hit. But writing repository methods carefully and using LINQ to do stuff that is complex to achive on database through mapper saves us a lot of time.Anonymous
July 23, 2008
No, so far we have not used LINQ yet, and I don't think that's gonna change soon. I think I'm the only one who read up on it, and already have a familiarity with functional programming since I had to take extensive courses at college dealing with Earlang and Haskell. I will use it in our next project I guess, against my work mates' will :)Anonymous
July 23, 2008
A couple of our developers started using LINQ 2 or 3 months ago on a large suite of applications. Talking with one of them last week, he said if he had to do it over again he would still use LINQ but would use it on top of stored procedures. He felt that LINQ'ing to the base tables in the database just made the code too verbose and complex. 2 or 3 weeks ago I started maintenance work on the suite of applications they developed. My first real use of Visual Studio 2008. My first impressions: I can see the attraction of LINQ - performing queries on objects. However it seems to me the implementation is flakey. Every time the setup projects that create the MSI files are built, a failure is reported. Yet there are no errors and the MSI files work perfectly. Sometimes the projects fail to build at all. The fix is to open the .dbml file, make a trivial change, save it, change it back to its original value again. Then the projects will build. I'm originally a database developer so, while I can understand the advantages of LINQ, I prefer to use stored procedures for all contact with the database. Why? Because the stored procedures act like an API for the database. Any action that affects the database can be done independently of the application code. Guess it boils down to encapsulation and separation of concerns - there is a discrete interface between the database and the application code which makes it much easier for me to debug and maintain. By the way, I've nothing against functional programming. I started using a functional style of programming years ago, before I'd ever come across the term. So much easier to develop, debug and maintain if the only inputs to methods / functions are their parameters. Cheers SiAnonymous
July 23, 2008
Our new project with best developers was developed using linq, both to sql and collections. Devs liked it, though this project is not in production yet. Our old project, where I work was converted to linq from plain db access. We are also happy, although adoption is also a problem, because linq2sql is not equal traditional SQL at all. It's pretty hard for me as average developer and is even harder for junior ones. But our experience is positive overall. The only things we don't like in linq is linq2sql related, hopefully, entity framework will fix them. I myself like C# functional approach much, it's hard to measure productivity, but it looks cool ;-)Anonymous
July 23, 2008
We are using the extension methods on IEnumerable but do not use the SQL like syntax. It combines much more easily with existing coding styles, while losing no functionality.Anonymous
July 23, 2008
We're using the extension methods extensively, but like Bart, we're avoiding the SQL-like syntax. The new lambdas, local type inference, and extension methods boost our productivity something awesome. Pretending its SQL doesn't seem to gain us anything. But then, we're not writing against a relational database. I've heard the DLinq tools don't always work quite right, so maybe that's a good thing.Anonymous
July 23, 2008
We have used Linq for www.yourtownfootball.com. It has made the site possible and cut my sec time by a factor of 4x. We launch on Monday.Anonymous
July 23, 2008
like many others here we use the extensionmethods for IEnumerable but not the pseudo-sql synthaxAnonymous
July 24, 2008
I will read your tutorial here soon. LINQ has been on my radar for review for a while now. I think introducing functional programming to the mort/dataset developers will make their heads explode and likely send them running towardzls their old habits.Anonymous
July 24, 2008
Dunno about other (external) projects, but I'm using it extensively in mine (internal). I don't know why there's a "learning curve" associated with it... isn't relational algebra now a part of the CS curriculum? In any event, LINQ really brings one of the best features of Python, generator expressions, to C#, and for that I thank the team.Anonymous
July 24, 2008
The comment has been removedAnonymous
July 24, 2008
The day I got my hands on VS2008 I reworked ~50% of our core product with LINQ for our data transformations (similarly using extension methods, not the SQL-like syntax). We make extensive use of expressions as well for type-/refactor-safe queries against our ORM. Now if only we could yield return from an anonymous function, we could have simple coroutines too. sighAnonymous
July 24, 2008
Started using LINQ but gave up. Were using WPF and LINQ is unusable in this context due to the inexplicably absent support for ObservableCollection. We tried the suggested workaround of maintaining parallel observable collections, but this was getting out of hand once you got past the fill a listbox example. Pity - maybe beta 2.Anonymous
July 24, 2008
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.Anonymous
July 24, 2008
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 ;-)Anonymous
July 24, 2008
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.Anonymous
July 24, 2008
The comment has been removedAnonymous
July 24, 2008
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 useSelect' andAny' thanAggregate' or evenSelectMany'.Anonymous
July 24, 2008
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...Anonymous
July 24, 2008
I start LINQ soon as Scott Guthrie started to blog about it. From that day on I haven't look back. LINQ is awesome.Anonymous
July 24, 2008
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.Anonymous
July 24, 2008
I use it and most others look in awe. I'm working on setting the situation straight, though :)Anonymous
July 24, 2008
The comment has been removedAnonymous
July 24, 2008
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.Anonymous
July 24, 2008
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!Anonymous
July 24, 2008
Eric White has written an interesting post titled "Are developers using LINQ?" - there are interestingAnonymous
July 24, 2008
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.Anonymous
July 24, 2008
Eric White has written an interesting post titled "Are developers using LINQ?" - there are interestingAnonymous
July 24, 2008
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.Anonymous
July 24, 2008
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.Anonymous
July 25, 2008
Eric: 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. LeoPasta: 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.Anonymous
July 25, 2008
I'm using LINQ with the ADO.NET Entity framework. it's very effective.Anonymous
July 25, 2008
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 ..Anonymous
July 25, 2008
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.Anonymous
July 25, 2008
We do not use link. We are not fully on 3.5 yet, and our DBA does not want it.Anonymous
July 26, 2008
> "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.Anonymous
July 26, 2008
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).
Anonymous
July 26, 2008
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.Anonymous
July 28, 2008
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.Anonymous
July 28, 2008
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.Anonymous
July 29, 2008
> 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.Anonymous
July 30, 2008
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.Anonymous
August 03, 2008
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. -EricAnonymous
August 07, 2008
We have three people out of roughly twenty who use LINQ, and we love it. That's probably because two of us have years of experience writing Haskell, and the third was introduced to Haskell (and liked it) by the first two. Now if only I could get QuickCheck for .NET!Anonymous
August 10, 2008
> There are legitimate reasons - some companies haven't moved to VS2008 yet, for instance. To be honest, it's becoming pretty hard not to do it, if only because a lot of bug fixes are restricted in VS2008 (some time ago, I've had a bug reported against VS2005 on Connect closed because it is fixed in VS2008). Also not to forget the removal of WPF designer for 2005.Anonymous
August 19, 2008
LINQ is required for any project in our corp now and once people get it they seem unhappy if they have to mess with legacy stuff that hasn't been converted yet.Anonymous
September 29, 2008
At work we don't use LINQ yet. We will soon though. For my pet (home) project (larger than my work project, haha) I use LINQ for all collection queries and SQL queries. It really is fantastic. Oh and if your goal is to abstract LINQ away from the tables, do what I do, use Views. Works perfectly.Anonymous
September 29, 2008
Yes, developers are using LINQ. However sadly, as with so many Microsoft technologies, they're paying the performance price because they don't understand it. When LINQ is used correctly (in memory objects) it's great and basically code better than you can. Nobody understands how to make the CLR hum better than the compiler writers at Microsoft. BUT when used against a SQL server for anything but simple selects it does some of the dumbest things I've ever seen. Sure, it's not as bad as other technologies, but nothing beats properly coded SQL; and NOTHING beats a properly architected database. LINQ is good for quick-n-dirty projects.Anonymous
September 21, 2009
No, I have not used it. I have looked at some of the concepts, but I have not really grasped it. I have not taken the time to understand the potential of it.Anonymous
October 23, 2009
I just recently stumbled across this post and your FP tutorial, which I am taking the time to work through over the coming weekend. Out of roughly 15 developers in the company I work for, I'm the only one that has had any interest in and put the effort towards learning LINQ. I worked through most of LINQ in Action (a great book) but I like the strictly FP approach of your tutorial. Additionally, I hope to use it as a stepping stone to learning F#. When I pitched LINQ at my job late last year, it was dismissed by the more senior developers as an amateur tool and that "real" developers hand-write their T-SQL. Of course, this statement also indicates they have no clue of the power of LINQ outside of LINQ to SQL. Since then I've used LINQ to Objects to create some fairly complex transformations very succinctly and elegantly. Once I'm a bit more comfortable writing as well as explaining LINQ, I will pitch it once more, this time with real-world examples from my own project to demonstrate.Anonymous
April 13, 2010
I think the question for a lot of us is, if we can already easily do what we need to do, why do we want to use something that complicates it? I can see the attraction of querying objects but lisp like languages syntax makes my stomach churn. When you know C# like the back of your hand, and you know T-SQL like the back of your hand, I haven't seen much that can speed development that's already fast and powerful. If you can efficiently and effectivly get the data you need, why add a middle tier? This isn't to say that LINQ doesn't have it's place... but for me, it's a preferance that I don't prefer. Plus, I'm leary when I hear "elegant", "succinctly", etc.etc. When we used classic ASP, we were told how old and clunky it was and how Web Forms were the future. Now, the same people are telling us that Web Forms are old and clunky and MVC is the elegant and best way to go (and it follows the same paradigm that was old and clunky 10 years ago... it's just got a more powerful framework behind it).Anonymous
April 13, 2010
Hi John, I fully understand that when developers are super-fast with very good technologies, the motivation to learn / move to something new is reduced. Of course, I was in the situation where it was my job to learn LINQ, but in the course of doing my job, I really became sold. Currently, my job doesn't require that I use or advocate LINQ, but I am still a huge fan. To me, the benefits boil down to the following:
- The code more closely matches what you are trying to do, instead of you telling the compiler how to do what you are trying to do.
- While very difficult to prove (and even controversial to talk about sometimes :), I believe that LINQ results in shorter code.
- You can take advantage of parallel processing more easily, although with Open XML (my main use of LINQ), I'm still I/O bound.
- Debugging is significantly easier. Pure functions (functions with no side-effects) are by definition easier to debug. If you have a given set of arguments, the returned value will always be the same.
- Maintenance is easier. Again, with pure functions, most maintenance of the code will take place in a single function/method. Very rarely will you have interdependencies between methods. In my opinion, what it boils down to is that with LINQ, you have to know more, but then you have to do less. The biggest detriment with LINQ is that it is harder to find developers to maintain. And that is a big problem for some folks, who simply can't afford to have a code base that is difficult to maintain. Recently, I wrote a conversion of WordprocessingML to XHtml (http://blogs.msdn.com/ericwhite/archive/2008/10/20/eric-white-s-blog-s-table-of-contents.aspx#Open_XML_XHtml). I believe that it would have been very difficult for me to singlehandedly write the same code in a traditional manner, but because I was using LINQ to do the transforms, was able to develop it in spare time. But of course, this judgement is purely subjective! :) Please don't take this wrong - I am totally not interested in arguing about this. I just think it is great to have this conversation. I think that time will tell whether we will see a transition to LINQ-like approaches, or whether we will continue to write more traditional OOP code. In 10 years, will we look back, and see this simply as a temporary trend, or as a sea-change? -Eric