[Blog Map] This blog is inactive. New blog: EricWhite.com/blog
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.
It 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.
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!
> 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.
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.
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.
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.
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.
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.
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).
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?