Blog Map
[Blog Map] This blog is inactive. New blog: EricWhite.com/blog
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.
I have seen four basic scenarios where folks use LINQ:
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.
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?
@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
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 :).
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.