A lot of us started seeing this phenomenon with jQuery about a year ago when people started asking how to do absolutely insane things like retrieve the query string with jQuery. The difference between the library (jQuery) and the language (JavaScript) is apparently lost on many programmers, and results in a lot of inappropriate, convoluted code being written where it is not necessary.

Maybe it's just my imagination, but I swear I'm starting to see an uptick in the number of questions where people are asking to do similarly insane things with Linq, like find ranges in a sorted array. I can't get over how thoroughly inappropriate the Linq extensions are for solving that problem, but more importantly the fact that the author just assumed that the ideal solution would involve Linq without actually thinking about it (as far as I can tell). It seems that we are repeating history, breeding a new generation of .NET programmers who can't tell the difference between the language (C#/VB.NET) and the library (Linq).

What is responsible for this phenomenon? Is it just hype? Magpie tendencies? Has Linq picked up a reputation as a form of magic, where instead of actually writing code you just have to utter the right incantation? I'm hardly satisfied with those explanations but I can't really think of anything else.

More importantly, is it really a problem, and if so, what's the best way to help enlighten these people?

  • 6
    +1 for "assumed that the ideal solution would involve Linq without actually thinking about it". It's really beyond me. Commented Sep 21, 2010 at 19:53
  • 1
    Linq is slow...
    – user2567
    Commented Sep 21, 2010 at 20:58
  • 2
    @Pierre: On what basis do you make that claim?
    – Aaronaught
    Commented Sep 21, 2010 at 21:07
  • 5
    @Mason: That is an absolutely horrible benchmark written by somebody who clearly does not know what they are doing. Benchmarking in ticks? Hungarian notation? And the Linq version does not even do the same thing, it tries to iterate every single result instead of stopping at the first. Not to mention, the entire premise is silly, as was concidentally discussed in the hot question of today.
    – Aaronaught
    Commented Sep 22, 2010 at 18:59
  • 3
    And, incidentally @Mason, Linq has many optimizations built in. For almost any method that is capable of being optimized, it first looks for an interface supporting the optimized method. For other set-based methods like equijoins, it creates hash tables. It doesn't optimize your code for you but it's not going to make your code any slower either; most of the actual documented real-world slowdowns are due to lambdas/closures which are independent of Linq.
    – Aaronaught
    Commented Sep 22, 2010 at 19:05

8 Answers 8


It's basically because programming is fundamentally difficult. It requires a lot of logical, structured thought in a way that a lot of people just don't know how to do. (Or simply can't do, depending on who you listen to.)

Stuff like LINQ and jQuery makes certain common data-manipulation tasks a whole lot easier. That's great for those of us who know what we're doing, but the unfortunate side effect is that it lowers the bar. It makes it easier for people who have no idea what they're doing to start writing code and make things work. And then when they run into reality, and find something fundamentally difficult that their simple, high-abstraction-level techniques are not well suited to, they're lost, because they don't understand the platform that their library is built upon.

Your question is sort of on the right track, but much like the perennial controversy about violent video games "turning kids violent," it has the direction of the link backwards. Easy programming techniques don't make programmers stupid; they just attract stupid people to programming. And there's really not much you can do about it.

  • 30
    +1 for "Easy programming techniques don't make programmers stupid; they just attract stupid people to programming." Commented Sep 21, 2010 at 18:06
  • 1
    One great thing about LINQ is it allows me to prototype a solution in a functional approach. Then once I have a bug free solution I can use it as a test bench for an optimized imperative version. If the task is simple enough like applying a single filter I won't even bother. Commented Sep 21, 2010 at 18:46
  • 5
    I'm still doubting that LINQ attracts incompetent programmers - from what I've seen, it seems to be one of the hardest concepts for newbies to understand - but, this seems to be the best answer so far.
    – Aaronaught
    Commented Sep 22, 2010 at 16:57
  • 1
    You should put a copyright on that last sentence. Well said, sir.
    – AJ Johnson
    Commented Nov 10, 2010 at 13:04
  • 1
    Funny. To me, LINQ is not a concept that's particularly easy to master. If you're doing anything of subtance, very quickly you need to stop thinking about the steering wheel and start understanding the transmission. I'm looking at you lamdas! Commented Aug 10, 2011 at 14:54

To me it's the new toy phenomenon. Something new comes out (LINQ) and now every developer wants to play with it.

They see LINQ as a hammer and every problem is a nail. Who cares if it's simpler to do it another way? LINQ must be the answer! Like when everyone was using XML for EVERYTHING! Configuration file? XML. Storing Data? XML. Etc etc

  • 5
    Not wanting to start an XML debate here, but it's worth pointing out that XML is actually good at both of those things. It's not always optimal - if configuration files don't need to be structured then KVPs are better, and if cross-application compatibility isn't a requirement then a binary format is clearly better for storage/serialization. But I don't think XML is such a great example because it tended to find itself being used in areas where it was merely sub-optimal as opposed to totally inappropriate.
    – Aaronaught
    Commented Sep 21, 2010 at 18:07
  • 4
    +1: It's worth-while to stretch your tools to see how many problems can be pounded into the shape of a nail when you're learning a technology. Commented Sep 21, 2010 at 18:15
  • +1: Other examples of this sort of magic hammer are jQuery (as mentioned in the question) and regular expressions. Not that these things are bad, in fact they're really useful, but they aren't the answer to everything. Commented Sep 21, 2010 at 18:56
  • 14
    I think that the "LINQ is a hammer and every problem is a nail" analogy is pushing it a little too far. I'd say LINQ is such a good hammer that when a large proportion of your work involves nails, you can get into a groove and not notice that you just hammered in a screw. Even if you aren't a bad programmer. Commented Oct 5, 2010 at 2:38
  • @Aaronaught: On the other hand, the use of XML with long field names seemed suboptimal to me for data transmission through low-bandwidth and not-entirely-reliable radio links. Then again, that's also what I thought of the database design on that product. Commented Nov 10, 2010 at 22:26

I think LINQ offers a really good opportunity in C# at solving problems using a more functional approach. We shouldn't dismiss a new style of problem solving just because we already have something that works.

Coming from a heavy SQL background, I like having the option of using set based logic in my C# to better describe the intent of my operations.

That said; context is king, and anything can be overused.

  • Who is dismissing? I use Linq all the time, I'm just concerned about the number of incidences I see of people using it (or attempting to use it) for problems that are clearly iterative and not set-based.
    – Aaronaught
    Commented Sep 21, 2010 at 19:00
  • I'm very accustomed to trying to solve problems that have been required to be written in SQL, and using set-based logic instead of cursors to do so. Tool abuse will always happen, but I guess at least if they write poor LINQ code instead of poor procedural code, a subsequent version of .NET will more easily at least be able to parallelize it.
    – dotjosh
    Commented Sep 21, 2010 at 19:46

LINQ and jQuery are the latest "toys" and developers love showing off how they can do stuff using the latest thing.

  • I agree with this statement. I'm not so sure if it explains this particular phenomenon. The people asking these questions don't really seem to be the show-off types - although it would help to explain why other programmers try to answer the questions as asked instead of advocating a saner approach.
    – Aaronaught
    Commented Sep 21, 2010 at 19:37
  • @Aaronaught - Yeah, I guess I was thinking more of why people answer with the questions using this approach.
    – Dan Diplo
    Commented Sep 21, 2010 at 19:40

If you use Linq properly, and understand it under the hood, you will find all sorts of new cutting-edge programming techniques.

So if you think deeply about the enhancements, I argue that it makes you a better programmer. Whether a given programmer actually does this or not, is not Linq's fault.

The same argument can be made for Object-Relational Mappers. Does anyone really write raw SQL queries against database tables anymore? :)

  • 10
    Hey, I write raw SQL... sniff
    – Aaronaught
    Commented Sep 21, 2010 at 18:11
  • 2
    Raw SQL is the best bet if you know what you're doing.
    – Fosco
    Commented Sep 21, 2010 at 19:29
  • 1
    +1 for the "makes you a better programmer" argument. Understanding linq and especially the methods that support it has definitely improved my grasp of some very helpful programming concepts. Commented Sep 21, 2010 at 19:30
  • 1
    I think somebody took offense to the ORM vs. raw SQL comment. It wasn't me; I use both, and I understood the remark as being tongue-in-cheek.
    – Aaronaught
    Commented Sep 21, 2010 at 20:58
  • 1
    I would never trust my complex database queries to the crap that an ORM writes, It's fine for simple stuff, but ugh for reporting type queries. Again, in the hands of someone who knows what they are doing ORM is a good thing, in the hands of someone who is too lazy to understand databases, disaster ahead.
    – HLGEM
    Commented Sep 21, 2010 at 21:22

Some of those insane things are because people are using the wrong hammer, others are because they are building a really elegant super-hammer, but they have run into an oddball detail that needs to be overcome.

For example, if you see a question about using linq to generate dynamic linq to use against non-dynamic linq nine times out of ten the person is either just curious if it is possible, or barking up the wrong tree, but there are a few things you can solve this way that are difficult to the point of unreasonable to solve otherwise.

I take these sort of questions in two parts:

  1. can it be done, and if so what would it look like
  2. should it be done, is there a risk, or a better alternative

I have found that I almost always do them in that order. It answers the question and also helps you make a better explanation for potential alternatives.


I don't know about any numbing effect on developers' minds but take a look here for the effect of numble-minded tools/languages on rates. Talk about lowering the bar!


I agree with Mason Wheeler. However, it is not entirely crazy to try to solve https://stackoverflow.com/questions/3762202/get-range-of-integers-with-linq by operating on a "sequence". The problem is that Java's and .Net's iterators do not support all 3 operations: current value, next value, and move to next. Clojure can do all 3, and I suspect that in Clojure it is easier to do this right. Python also has co-routines, and I want to try cracking that. http://clojure.org/sequences http://www.try-clojure.org/

In fact, if the input is an infinite sequence, such as http://oeis.org/A007401, then lazy is the only way.

  • "Linq" does not mean "iterators" nor "lazy" necessarily - in fact, most of Linq is really about expression trees. You could easily, if you wanted, implemented your own 3-valued or N-valued aggregate with a closure and not very much code at all in C#. The trouble comes when people have no idea how to actually do that, or even how to get started, and are just looking for some magic incantation that lives in the System.Linq namespace.
    – Aaronaught
    Commented Jun 26, 2011 at 6:05
  • @Aaronaught ... '''"Linq" does not mean "iterators" nor "lazy" necessarily''' - well, Linq can look like SQL but this syntactic sugar compiles into an actual IL code, which, if de-compiled, would look equivalent to a bunch of IEnumerable[<T>]s hooked up together. That stuff is lazy and uses enumerators, which in other languages would be called iterators. But yes, the problem is that LINQ makes coding looks easy, and the unqualified try it. Some still might become decent programmers perhaps. If C# is their first language and they are total noobs, then they are dealing with a large language.
    – Job
    Commented Jun 26, 2011 at 15:13
  • Sure, Linq to Objects (not Linq to SQL, Linq to Entities, Linq to DataSet or any other branch of Linq) is based on iterators and deferred execution, but that's all under the hood. Iterator blocks and the yield statement existed before Linq, as did delegates. Closures came in the same release as Linq, but few pure "Linq" operations actually require local variable capture. Asking "How can I do [description of entirely iterative operation/function] with Linq?" betrays a profound ignorance of both Linq itself (what it's meant to do) and the language itself.
    – Aaronaught
    Commented Jun 26, 2011 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.