Are Developers Using LINQ? (Part 2)

The response to my previous blog post has been very interesting to me.  And it has, to a very large extent, matched my own experience.

This blog is inactive.
New blog:

Blog TOC
I have seen four basic scenarios where folks use LINQ:

  • Using LINQ to Objects (and LINQ to XML, which is really just LINQ to Objects), primarily using the extension methods, and the so-called ‘method syntax’.  This really is a great scenario.  When I really understood it, it blew my mind.  I believe it leads to the possibility of “speed-reading” code – see below.
  • Using query expressions (query comprehensions to the FP crowd) to access objects and XML.  I have mentioned in previous posts that I have naturally gravitated away from these.  Why?  They are not really necessary, and I find that I often have to go outside of them.  I’ve thought of coding idioms to deal with this in a better way than parenthesizing query expressions, and ‘dotting’ into the extension methods I need to perform my desired transformation, but I think that ‘method syntax’ reads better.  In any case, query expressions are syntactic sugar, and when you get really comfortable with lambda expression syntax, to me, it’s just clearer.
  • Using LINQ to SQL or LINQ to Entities to access a database.  I haven’t used these much.  I’ve been in XML land for quite a while.  (I’m a database / accounting application / management information system developer from way back.  When you live in the boondocks in Colorado, as I have much of my life, this is what pays the bills, so this is what you do.  I’ve designed more databases and written more CRUD (Create, Read, Update, Delete) applications than I care to count.)
  • Using LINQ implemented using an IQueryable provider to something other than a SQL database.  I’ve never personally used one, but feel it has huge potential.  I think it depends on the quality of the implementation.

Speed Reading Code

This is one of the random benefits that I think you gain from using the FP style of code.  One of the techniques that is possible, I believe, is that after becoming fully competent/clear/conversant with C# 3.0 syntax, is that it is possible to ‘speed read’ code.  You can look at the code with an eye towards identifying the relevant transformations, and see large blocks of code as a single unit.

When I go back to code that I wrote two years ago, and can read my own code quickly, I appreciate it.  Hey, when you are as old as me, the jokes about meeting new friends every day because you can’t remember them from yesterday are not as funny.  😀

Anyway, the responses to the previous post mirror my own experience.

One thought I have about the responses – there is only a small percentage of negative responses.  But I would bet that many who are not using LINQ haven’t left their comments. This is the expected outcome of an extremely biased poll like the one I posed.  If you are not using LINQ, please comment!

In any case, I feel that there are enough folks who do get it, and who are using LINQ in its intended, most effective form, that the transition to a new FP main-stream world has begun.  Slower than I’d hope, but probably not slower than I’d expect.

Comments (4)

  1. MichaelGG says:

    So what do you think about F#? C# 3 did a good job and got many scenarios down well (query in particular), but more FP becomes painful. Since F#’s capabilities are nearly a superset of C#’s – what’s that mean to you?

  2. @MichaelGG,

    I think that F# is very cool.  There are certain .NET scenarios where F# is the only language that makes sense – a compiler where the code mirrors BNF closely, for example.

    One thing that motivates me is wide-spread adoption.  I really like working on projects that ship to a large number of developers/users.  I think that the more advanced F# type system will leave a large number of developers behind (sad, but true).  This doesn’t diminish the importance of F# – I’m really happy that Microsoft is going to productize it.  I just think that its going to leave behind a large number of Mort and Elvis developers.  (

    My hope is that the improvements in C# will start to drive main-stream adoption of FP techniques.  When developers reach the limits of C#, then there will be a natural progression of a certain subset of developers to F#.


  3. MichaelGG says:

    Hi Eric,

    You may be right, I just don’t understand why it is like that. F# doesn’t require you to understand the "advanced" features, and, unlike, C[++], I don’t think there’s many "gotchas".

    "Elvises go to school and get CS degrees." – Having not gone to school, shouldn’t anyone with a CS degree be able to comprehend FP? (That’s not rhetorical.)

    At any rate, wasn’t VB designed to deal with Mort, so other languages could expand more?

    Anyways, thanks for the viewpoint :).

  4. Steve says:

    I haven’t wrapped my head around LINQ yet because the application I work on already has an extremely robust object layer that was originally developed in .NET 1.1.   The object model hasn’t changed significantly with the exception of additional features over time.

    Our objects already handle lazy loading, relational loading, creating, updating and deleting an object and it’s relationships within a transaction.  The objects will automatically save the master and related detail records if changed etc…

    The objects also are smart enough to know when they are dirty to skip saving, and only save the fields that changed.  

    So essentially we’ve created an extremely robust object model that is mapped to tables and fields just as LINQ would.  We are able to generate classes using generator tools very rapidly (although we don’t do this much since our database is mature and the application is stable).

    We spend most of our time dealing with UI and AJAX.  We have been able to spend our time on those types of things instead of LINQ because we already have a great system.

    So now I question, should we use LINQ.  I don’t know, right now it doesn’t really make sense because we’d de-stabilize tested and robust commercial grade application code and a published SDK that goes with it.

    What I wonder now though is this…. perhaps we could extend our existing classes and collections to implement the LINQ Interfaces and keep our existing data object layer intact.   Since we have a very consistent data access layer which uses the SQLDataReader object… if we found benefit in using LINQ to SQL, we should be able to change our objects to utilize LINQ where advantageous.

    So I guess if you’re like us, which has a robust application which was developed in .NET 1.1, moved to 2.0 and 3.5 over the years and it’s very stable and performs well, then why would we want to abandon that?  To me it just doesn’t seem to make sense, but maybe it does?  Time will tell for us.  We (our dev team) definitely are open to learning new things and we’re all very experienced as well…. but there has to be a pretty big ROI to take this big of a risk to shift to LINQ.  If we ever do for our main application, it will be with caution and slowly.   Ideally, we’d give it a go on some new feature or function or application that gets folded into our suite.

Skip to main content