Freigeben über

Are Developers Using LINQ? (Part 2)

  • Artikel

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: EricWhite.com/blog

Blog TOCI 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.  :D

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

  • Anonymous
    July 25, 2008
    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?

  • Anonymous
    July 27, 2008
    @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.  (http://blogs.msdn.com/ericwhite/archive/2006/05/11/who-are-mort-elvis-and-einstein.aspx) 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#. -Eric

  • Anonymous
    July 27, 2008
    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 :).

  • Anonymous
    March 23, 2009
    The comment has been removed