Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
5  
+1 for "assumed that the ideal solution would involve Linq without actually thinking about it". It's really beyond me. –  Jaco Pretorius Sep 21 '10 at 19:53
1  
Linq is slow... –  user2567 Sep 21 '10 at 20:58
2  
@Pierre: On what basis do you make that claim? –  Aaronaught Sep 21 '10 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 Sep 22 '10 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 Sep 22 '10 at 19:05
show 4 more comments

8 Answers

up vote 50 down vote accepted

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.

share|improve this answer
28  
+1 for "Easy programming techniques don't make programmers stupid; they just attract stupid people to programming." –  Steve Evers Sep 21 '10 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. –  ChaosPandion Sep 21 '10 at 18:46
4  
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 Sep 22 '10 at 16:57
1  
You should put a copyright on that last sentence. Well said, sir. –  AJ Johnson Nov 10 '10 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! –  Brian MacKay Aug 10 '11 at 14:54
show 4 more comments

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

share|improve this answer
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 Sep 21 '10 at 18:07
3  
+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. –  Steve Evers Sep 21 '10 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. –  Tim Goodman Sep 21 '10 at 18:56
11  
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. –  Carson63000 Oct 5 '10 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. –  David Thornley Nov 10 '10 at 22:26
show 1 more comment

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.

share|improve this answer
    
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 Sep 21 '10 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 Sep 21 '10 at 19:46
add comment

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

share|improve this answer
    
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 Sep 21 '10 at 19:37
    
@Aaronaught - Yeah, I guess I was thinking more of why people answer with the questions using this approach. –  Dan Diplo Sep 21 '10 at 19:40
add comment

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? :)

share|improve this answer
9  
Hey, I write raw SQL... sniff –  Aaronaught Sep 21 '10 at 18:11
1  
Raw SQL is the best bet if you know what you're doing. –  Fosco Sep 21 '10 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. –  John M Gant Sep 21 '10 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 Sep 21 '10 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 Sep 21 '10 at 21:22
show 9 more comments

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.

share|improve this answer
add comment

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!

share|improve this answer
add comment

I agree with Mason Wheeler. However, it is not entirely crazy to try to solve http://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.

share|improve this answer
    
"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 Jun 26 '11 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 Jun 26 '11 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 Jun 26 '11 at 15:33
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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