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.
PingBack from http://blog.a-foton.ru/2008/07/are-developers-using-linq/
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.
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.
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 :)
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.
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 ;-)
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.
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.
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.
like many others here we use the extensionmethods for IEnumerable but not the pseudo-sql synthax
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.
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.
Yes, we use LINQ to Objects and XLINQ here on the most recent project, though also mostly using the functions directly, without the SQL-like syntactic sugar (but then again, we don't have any queries complex enough that they'd be any shorter in SQL style).
It actually came quite naturally since we had a lot of methods returning IEnumerable<T> that were implemented using iterator blocks - in such an environment, LINQ fits right in.
We will also very likely use LINQ in general and Entity Framework in particular for the next major version of our mainline product (which is a SharePoint application), as it is certain now that we'll be moving to 3.5.
For what it's worth, so far, I haven't heard any "get off my lawn" kind of complaints with regards to LINQ from our veteran developers.
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. *sigh*
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.