Talk:Language Integrated Query

Introduction

I'm open to other opinions but to me (as a developer of many years), the introduction seems overly complex - It makes sense to me but wouldn't mean anything to most non-developers I know. I'm aware it's a complex topic and specifically a programming one but something along the lines of "It allows developers to integrate database [data store?] queries into their code far more easily with strong typing whilst removing the risk of SQL injection attacks" or similar would be more comprehensible. I'm not a frequent editor so go easy on me... Basiclife (talk) 02:35, 18 December 2010 (UTC)

Feel free to change the introduction. But make sure that some of the stuff mentioned remains in the article (event handlers, parsers...). I've introduced these as some kind of arguments for why the article was bad and bordering on incorrectness by being too specific to collections and queries. (Btw., new discussions should be started at the bottom of a talk page. Yeah, I know this is strange, and I've violated it quite some time, but that's how it seems to be customary.) --Daniel5Ko (talk) 23:00, 6 January 2011 (UTC)

Historical background: I think it would be good to mention/link to the programming language Pizza (a Java extension). - It uses the concept of "fluent interfaces" to query data in a declarative manner and that is in principle identical to LINQ (http://en.wikipedia.org/wiki/Pizza_programming_language).--Nico22101978 (talk) 08:36, 17 July 2011 (UTC)

Thank you for your suggestion. When you believe an article needs improvement, please feel free to make those changes. Wikipedia is a wiki, so anyone can edit almost any article by simply following the edit this page link at the top.
The Wikipedia community encourages you to be bold in updating pages. Don't worry too much about making honest mistakes—they're likely to be found and corrected quickly. If you're not sure how editing works, check out how to edit a page, or use the sandbox to try out your editing skills. New contributors are always welcome. You don't even need to log in (although there are many reasons why you might want to). Diego (talk) 10:22, 17 July 2011 (UTC)

Tons of problems with this article

And I think a lot of it stems from not actually understanding LINQ or LINQ 2 SQL.

Rather than trying to tease apart a bunch of frequently interchanged and misused terms, here's all the constituents of both technologies.

1. Lambdas --- inspired by the lambda calculus, these are anonymous delegate declarations in a type-safe wrapper

2. IEnumerable --- an interface describing a sequence

3. Iterator blocks --- Code blocks which enable generation of items in an IEnumerable sequence on request, enabling deferred execution

4. Extension methods --- Allows programmers (including BCL programmers) to augment the APIs of types and interfaces with additional methods. Is really syntactic sugar for static "utility" methods.

5. BCL IEnumerable extension methods --- Extension methods on IEnumerable which enable operations on IEnumerable sequences.... for example Select(map), Where (filter), Aggregate (lfold), etc.

6. Query syntax --- Depending on the context, is syntactic sugar for either the BCL IEnumerable extension methods, or BCL IQueryable extension methods

7. IQueryable --- A specialization of IEnumerable, which maintains an internal representation of itself as an Expression tree

8. Expression Trees --- Data structures representing code

9. Query Provider --- A mechansim which interprets an IQueryable's expression tree to provide a roughly equivalent query written in another language, like SQL

1 + 2 + 3 + 4 + (optionally) 6 === "Linq 2 Objects" 1 + 2 + 4 + (optionally) 6 + 7 + 8 + 9 == "Linq 2 Sql"

Not well written article full of errors

This article is not that well written and actually full of errors. For example, lambda's aren't really part of 'linq'. Linq's mechanism uses lambda's but lambda's aren't part of linq. This paragraph:

Queries written using the query operators are executed either by the LINQ query processing engine or, via an extension mechanism, handed over to LINQ providers which either implement a separate query processing engine or translate to a different format to be executed on a separate data store (such as on a database server as SQL queries (DLINQ)). The results of a query are returned as a collection of in-memory objects that can be enumerated using a standard iterator function such as C#'s foreach.

is wrong at so many levels I don't know where to start. it's likely due to the fact it's rather old (considering the fact it refers to the name 'DLINQ' which is not only replaced with Linq to sql for some time now it's also not representative for executing sql queries on databases.

One of the core issues people have with Linq as a mechanism is where is the query executed? that mechanism is quite simple once you understand it but it's quite complicated to explain and this article doesn't do a great job in that, as it has to start with that instead of the remarks about

Actually, LINQ is much more general, in that it is not limited to querying data. In fact, it can be used as a general scripting framework with a "programmable semicolon". And what the meaning of the semicolon is, is determined by which methods or extension methods are available given the operands.

, which I think are a reference to fluent interfaces based on extension methods but similar to lambda's, extension methods are a mechanism used by the Linq mechanism, they're not part of it.

I've written a full linq provider in 2008 and have written many blogposts about it, so if someone wants me to assist in cleaning up this article, please let me know: frans AT sd DOT nl. --Otis Inf (talk) 10:34, 15 November 2009 (UTC)

I agree wholeheartedly with the article being so wrong that one can't know where to start cleaning it up. It is also quite limited to the idea of querying data and centered around getting IEnumerables as the result of a LINQ expression. The last quote you cite is from me. With "programmable semicolon", I wanted to point out the the similarity to Haskell's do-notation and the relation to monads in general (SelectMany is the monadic bind).

What is missing (and I don't know how to fit in without rewriting everything): First, LINQ defines purely syntactical rules for how a LINQ expression is translated to a bunch of method calls (if these are real or extension methods is not decided in that stage) and lambda expressions (and if these evaluate to delegates or expression trees is also not decided in this stage). Only after this translation, the methods and extension methods in scope and their signatures give a meaning to the whole thing. Second, the LINQ spec does not actually constrain the signatures of the methods used in any way. This makes writing libraries like the .NET Rx framework possible, which are intended to be used via LINQ, but have not much to do with actually querying data. Daniel5Ko (talk) 12:11, 17 November 2009 (UTC)

Meh, even Drpixie, allegedly having a CS PhD, doesn't get it. Probably it's futile... People: Read the LINQ specs, look up monads, get a clue. dammit. Daniel5Ko (talk) 12:13, 20 November 2009 (UTC)

The section regarding performance must also be revisited, as the external reference that this premise is based on is flawed in it's approach. The article used 3 mechanisms to count the number of odd numbers but the Linq version required the creation of a temporary result thus requiring two passes, whereas a for loop and for-each just incremented a counter. — Preceding unsigned comment added by Slaneyrw (talk • contribs) 02:54, 22 May 2012 (UTC)

Mostly wrong?

The assumption of collections and IEnumerable pervades the whole article. But in fact, LINQ expressions are translated more or less to C# source code without any type assumptions. Whatever Select or Where etc. happens to be in scope is used. For example,

static class IdentityMonadPlus {
	public static T Where<T>(this T x, Func<T, bool> p) {
		if(p(x)) return x;
		throw new Exception("something went wrong");
	}
	
	public static U Select<T,U>(this T t, Func<T, U> f) {
		return f(t);
	}
}

class Program
{
	public static void Main(string[] args)
	{
		var result = from x in 7
			         where x != 5
			         select x;
		Console.WriteLine(result);
	}
}

is perfectly possible. Should we strive to make that more clear? Daniel5Ko (talk) 21:03, 5 April 2009 (UTC)

While you are right in the first part, the second code snippet won't compile. Because C# is a statically typed language, and whatever you do, types are always checked at compile time (technically, with C# 4 dynamic type, you can defer it till runtime). The var doesn't make it type-less; just that you won't have to manually enter the type, it will be inferred. In the generated IL it will still have all type annotations.

How LINQ operates is this:

var p = from x in y
        where CheckSomething(x)
        select new { x.SomeAttribute };

Here first the type of y is inferred and if it has an implementation of .Where() [by default, only IEnumerable<T> provides the extensions that make LINQ possible; thats why only IEnumberable is mentioned], it is bound to. If the return type of .Where() has an implementation of .Select() it is then bound to. And p is declared to the the same type as the return type of .Select().

If someone wants to elaborate, please do so.--soumyasch 02:54, 6 April 2009 (UTC)

It compiles. Try it out. The type of x in the LINQ expression in my example is int, and the type of result is int as well. Daniel5Ko (talk) 07:17, 6 April 2009 (UTC)

Of course it will. You provided the implementation of where on type int. Actually, you did it for an unconstrained generic type which int matches to. Put any constraint on the generic types and you will see the compiler complaining of type mismatch, proving that LINQ expressions are not without type assumptions:

   static class IdentityMonadPlus
   {
       public static T Where<T>(this T x, Func<T, bool> p) where T: IDisposable
       {
           if (p(x)) return x;
           throw new Exception("something went wrong");
       }

       public static U Select<T, U>(this T t, Func<T, U> f)
       {
           return f(t);
       }
   }

   class Program
   {
       public static void Main(string[] args)
       {
           var result = from x in 7
                        where x != 5
                        select x;
           Console.WriteLine(result);
       }
   }

Hmmm. From the spec:

The C# 3.0 language does not specify the exact execution semantics of query expressions. Rather, C# 3.0 translates query expressions into invocations of methods that adhere to the query expression pattern. [...] The translation from query expressions to method invocations is a syntactic mapping that occurs before any type binding or overload resolution has been performed. The translation is guaranteed to be syntactically correct, but it is not guaranteed to produce semantically correct C# code.

And that means you can do much more than just querying collections. I find it wrong to make the impression that LINQ expressions are limited to that. Because they're not. —Preceding unsigned comment added by Daniel5Ko (talk • contribs) 18:10, 7 April 2009 (UTC)

As witnessed by the recent Rx framework, it seems that the full generality of LINQ is actually "officially" used. And that makes at least the introduction of the article almost completely bogus. What can we do? Is it appropriate to talk of monads? While this might be more close to reality, it might also turn this article to being about generalized abstract nonsense. Ideas? 21:34, 2 November 2009 (UTC) —Preceding unsigned comment added by Daniel5Ko (talk • contribs)

linq

Having used LINQ in a project for the past 2 weeks, I am amazed at the power it gives developers. Instead of having to mix my code with SQL, I can treat the database tables as if they were classes. The current release of LINQ still lacks intellisense but it had enough added value to move my project into it. Performance is also impressive.

--Ohadgliksman 13:13, 24 April 2006 (UTC)

Haskell influence

You guys might want to add some historical detail in; from pg 6 of "The History of Haskell":

But many of the features in C# were pioneered by Haskell and other functional languages, notably polymorphic types and LINQ (Language Integrated Query). Erik Meijer, a principal designer of LINQ, says that LINQ is directly inspired by the monad comprehension in Haskell.

--maru (talk) contribs 02:25, 15 July 2006 (UTC)

Those features werent there in imperative languages, and c# is not a functional language (like haskell, lisp) but an imperative one (like c, c++, java) --soum^সৌমোyasch 06:15, 15 July 2006 (UTC)

http://blogs.msdn.com/charlie/archive/2007/01/26/anders-hejlsberg-on-linq-and-functional-programming.aspx Dpser 09:38, 26 June 2007 (UTC)

Didnt I already say that this is bringing functional programming constructs to imperative languages? --soum ^talk 09:41, 26 June 2007 (UTC)

No, and what if you did? I just posted the link in case you find it useful for addition... Dpser 08:13, 28 June 2007 (UTC)

Oh ok, I thought you added the link with respect to the debate we had been having a year back. Thats why if you are saying something that is unrelated to a previous conversation, its best to start a new section and set some context. --soum ^talk 08:27, 28 June 2007 (UTC)

Release date

I am confused why you have deleted my paragraph Soumyasch. It was there to explain the apparent pushing back in release from .NET 3.0 to 3.x (ie it won't be in the Vista release cycle, yet this has been promised for 12 months). But your reason for deleting was simply 'not in 3.0' !! Please explain.

In the mean time, I have replaced the section with one not explicitly mentioning a previously planned release in 3.0 - I feel it is important people know this tool won't be available in the Vista cycle, as was previously the impression.

80.177.152.35 09:04, 13 August 2006 (UTC)

I deleted it bcoz it was never supposed to be released with .NET 3.0 (which is WinFX, still CLR 3.02.0), it was (and still is) to release with C# 3.0, and the version of CLR (presumably 3.0) accompanying it. The previous version gave an impression otherwise. --soum^সৌমোyasch 09:23, 13 August 2006 (UTC)

Ok, how about fixing it next time instead of hitting the Delete key ;) BTW Linq still produces 2.0 IL.

Incidentally, if Orcas is released sometime after Vista, what do we use to develop WPF / WCF apps in, during that period? Some expansion pack for VS2005?? (not CTP's obviously, since they're not of production quality). 80.177.152.35 14:23, 13 August 2006 (UTC)

Linq doesn't produce IL 2.0, Linq preview does. Who knows whether the release version will make use of IL additions or not! And WPF/WCF are essentially additions to FCL, so VS 2k5 is enough. Maybe add-in packages will make the IDE WinFX aware, meanwhile.

And as far as deleting goes, ur lines were from the assumption Linq was supposed to be in .NET Fx 3.0, so nuking it seemed best, so that revision of the statement wont be born from the misconception.--soum^সৌমোyasch 16:05, 13 August 2006 (UTC)

You might find this interesting http://msdn.microsoft.com/chats/transcripts/vstudio/05_1020_csharplinq.aspx , specifically "C# 3.0 will work on .NET Framework 2.0" (daigoh, QA at Microsoft). Also, when someone asks if it's appropriate to ask about .NET 3.0 enhancements in a 'C# 3.0 / Linq' chat, Jomo replies "I think 3.0 questions are appropriate". No ambiguity about that, he's talking about .NET 3.0, suggesting strongly the two are tightly connected (at least when this chat took place)

Also http://msdn.microsoft.com/chats/transcripts/vstudio/05_0922_csharp.aspx does not make a distinction between C# 3.0 and .NET 3.0, again the two are referred to as if they were part of a single release cycle (Vista).

The situation has changed now, obviously. But then, that was the point of my original post! I'm providing lots of references. Can you provide some to show .NET 3.0 has *always* been planned for release before / seperately from C# 3.0?? 80.177.152.35 17:54, 13 August 2006 (UTC)

The confusion stems from the fact that the current ".NET 3.0" release previously (for example in September 2005) was not assigned a special .NET version number, but instead was called "WinFX". At that time (and this is the time the chat transcript you linked stems from), ".NET 3.0" was used to (informally) denote the next platform upgrade (including C# 3.0, LINQ, and maybe even a new CLR 3.0), whereas "WinFX" was a set of libraries (originally for Vista only).

In the meantime, it was decided that WinFX should go into the main .NET libary. This library update is now called ".NET 3.0" and does not contain a change of the underlying platform or the standard compilers. What was once informally called ".NET 3.0" (i.e. C# 3.0, LINQ, etc) is now usually referred to as "Orcas" (which is the name of the next VS version), some also call it ".NET 3.5". See also Microsoft_.NET_Framework.

I think it was never intended that LINQ should ship together with WinFX, it's just the assignment of a whole .NET version number to WinFX which leads to this confusion. 128.130.173.30 10:55, 27 November 2006 (UTC)

Lead

Language Integrated Query (LINQ) is a Microsoft project that adds a native querying syntax reminiscent of SQL to .NET Framework programming languages, initially to the C# and Visual Basic .NET languages. Many of the concepts that LINQ has introduced were originally trialled in Microsoft's Cω research project.

I dont think this is entirely correct. LINQ is implemented basically by using a few generic methods - Select<T>, Where<T> etc etc + IQueryable<T> and implementations of this is what is the crux of LINQ. As such it is available to all .NET languages, not just C# ad VB.NET even in the initial release. Though the query syntax (which is just syntactic sugar for these functions) is currently limited to C# and VB.NET (+ implicitly typed variables) - but they are not the major components of LINQ (though, the most visible).

As such, I would suggest a rewrite. Just dunno how best to phrase it. --soum (0_o) 06:02, 10 April 2007 (UTC)

I disagree. The clue is in the name: 'language integrated' means it's integrated into the language. Without the language integration what you'd be left with is a framework for performing queries, and a number of providers for specific data sources. i.e, 'LINQ' minus 'LIN'. Forgotten account 14:04, 22 April 2007 (UTC)

What are you disagreeing with? That it will work without the language extensions? I never said that the language extensions were not part of LINQ. I just said the project is not limited to having them in the language - querying will work even without the querying syntax, only will not look as elegant - and that should be made clear. And that means making clear that the queries are actually converted by the compiler into equivalent method calls. --soum (0_o) 14:46, 22 April 2007 (UTC)

Read my comment again - I disagree that 'LINQ' is available to all languages regardless of whether they have language extensions. The underlying libraries are plain .NET - that is not in question. However the language extensions are a key part of LINQ: three quarters of the acronym 'LINQ' is dedicated to fact that language extensions integrate the facility into the language! :-) Forgotten account 12:50, 30 April 2007 (UTC)

:) Even I am not saying that. I am saying that not having the syntactic extensions will not prevent any language from using the libraries to guery data stores, though the end result might not look as declarative. Its the emphasized part that should be clarified - whether someone calls it LINQ or not is not my botheration. --soum (0_o) 13:01, 30 April 2007 (UTC)

External Reference Wiki Site

I added a link to my Wiki dedicated to LINQ http://www.hookedonlinq.com and it was removed. It is a community Wiki that is very active with over 100 pages of reference being added in under 4 months. Now I can see that you don't want every link to a website (which would make this a directory rather than reference), however, when that site is community run, and dedicated to a topic, and a reference site on that subject, I think it might serve the reader well to have the option of clicking on a link.

The website itself contains documentation to every Standard Query Operator http://www.hookedonlinq.com/StandardQueryOperators.ashx (eg. http://www.hookedonlinq.com/AverageOperator.ashx), and 5 minute overviews of the various flavors (eg. http://www.hookedonlinq.com/LinqToSQL5MinuteOVerview.ashx). It also has a spot for other links that may not be suitable for this Wiki page.

I'd like this site to be re-considered for inclusion of the external links. —The preceding unsigned comment was added by T magennis (talk • contribs) 23:05, 22 April 2007 (UTC).

The external links guidelines suggests that wikis should be avoided. Acting on that only was the link removed. However, many things like the LINQ operators and discussion on various flavors can be integrated into this article or daughter articles. Also, since the wiki may be useful, I think creating a directory and linking it from there may be warranted. --soum (0_o) 03:28, 23 April 2007 (UTC)

Actually the "Wiki's should be avoided" style guideline is not a blanket rule to not link to wiki's, the full guideline says:

"Example of links normally to be avoided: 12. Links to open wikis, except those with a substantial history of stability and a substantial number of editors."

The Hooked on LINQ wiki is publically open and editable, and the 40 current contributors are the authors of LINQ books from many publishing houses. The site is growing at 50 pages every couple of months, and will be over 250 by the end of May.

I understand the intent of the guidline; but I think linking to specific detailed public reference Wiki's that are maintained by the relavent community was not intended target to be avoided. Nobody is making money from the Hooked on LINQ site, its the aggregation of knowledge from its contributors; I'm happy to drop the idea of a link if its against the spirit of Wikipedia; I just think the content that resides there would benefit the readers of this article. —The preceding unsigned comment was added by T magennis (talk • contribs) 05:56, 23 April 2007 (UTC).

True a guideline is not binding, but it reflects consensus many editors have decided on. Plus a link is not enough to judge if it has a substantial history of stability and a substantial number of editors, for a non member. I would go with consensus on this one. --soum (0_o) 12:46, 23 April 2007 (UTC)

I've had a look at the site, and it seems sufficiently informative (and accurate) to be deemed acceptable, and the "support your site" link at the top is not intrusive. However if the list of external links on this article grows out of control, this link will need to be reconsidered. User:T magennis, what license is used for the content on your site? John Vandenberg 13:07, 23 April 2007 (UTC)

NHibernate

I added NHibernate to References and someone removed it. It should not have been removed. NHibernate provides ORM, yes overlapping with LINQ but also you can LINQ to NHibernate. Thus it is not only an alternative. --Kibbled bits (talk) 21:47, 15 April 2008 (UTC)

What is it that you want to achieve by adding the link? Why should someone want to "see also" NHibernate when they want information about LINQ? Isn't that shoving your preferences down others throat? Thats seriously POV. The "See also" section is used for linking to articles that are directly related to an article's subject. Not everything in the world that is tangentially related. ORM is the concept that LINQ deals with, it makes it directly related. How does NHibernate fit in? LINQ and NHibernate can perfectly live without each other. And again, on what basis have you added NHibernate but left out every other ORM app out there?

Also, what context just having a link to NHibernate provide? Just an out-of-place link with no explanation of what is interesting to see - why would readers want that? You want to say that you can LINQ to ORM, put it in "Other LINQ Providers" section, that provides a lot more context and provides a lot more information without the users - who don't want to see the NHibernate article also - without having to leave the page. If you have added it there for easy navigation (I am assuming in good faith that you were not advertising), well see also isn't a navigational or organizational device. If you want to organize all ORM-related apps, use a Category. If you want to promote navigation, use a navbox. --soum ^talk 02:35, 16 April 2008 (UTC)

It belongs here. First there is the Linq to NHibernate provider in addition to NHibernate being a similar or competitive idea. I would also like to cite Java (programming language) which has a See Also to C#. So either NHibernate is fine with this article or we need to remove C# from the Java article. I don't care so long as there is consistency. --Kibbled bits (talk) 19:02, 24 June 2008 (UTC)

I think than more than that, LINQ is also a way to address Object-relational mapping on .NET, like others like Hibernate (on Java) or its .NET port NHibernate already do. That LINQ has something to do with ORM (see this article on MSDN) is not clear at all in this article. ORM was not even in the See also list (I just added it). LINQ did not come from thin air, after all. Hervegirod (talk) 19:43, 20 September 2008 (UTC)

What's a "group join"

There is a link to SQL Join article from "group join" link in the LINQ article. But "group join" is not mentioned anywhere in the SQL Join article. I have been using SQL for many years and have not heard the term "group join" before. Can someone either add "group join" to the SQL Join article, or elaborate on it in this article? Lmcphee69 (talk) 14:08, 24 June 2008 (UTC)

Group join is a concept which has no direct equivalent in SQL because it produces a set of sets of hierarchically correlated objects. Consider the following LINQ query:

var accountsWithOrWithoutAssociatedOrders =
                from account in accounts
                join order in orders on account.Id equals order.AccountId into accountOrders
                select new { 
                    Account = account,
                    Orders = accountOrders 
                };

Note that accounts which have no corresponding orders will be included in the result, their orders being an empty IEnumerable<Order>.

Note that the following query, which does not use the group join construct is semantically equivalent:

var accountsWithOrWithoutAssociatedOrders =
                from account in accounts
                select new {
                    Account = account,
                    Orders = from order in orders
                             where order.AccountId == account.Id
                             select order
                };

In either case the results of the query are not flat. We need not call an aggregate function because it is perfectly acceptable for a LINQ expression to result in a sets of sets and other arbitrarily nested data structures.

Aluan Haddad (talk) 03:47, 7 May 2014 (UTC)

LINQ to Objects is dynamic

LINQ to Objects is dynamic! Consider the following example:

int [] nums = { 1, 2, 3, 4, 5};

var selection = from i in nums where i > 4 select i;

foreach (var num in selection)
{
  Console.WriteLine("{0}",num);
}

Console.WriteLine("==");

nums[0]=10;

foreach (var num in selection)
{
  Console.WriteLine("{0}",num);
}

Output is:

5
==
10
5

Conclusion: LINQ to Objects is dynamic!

This behavior is well-documented in MSDN, and is called "deferred execution". If you open documentation for almost any extension method in class System.Linq.Enumerable, in the "Remarks" section, the very first paragraph usually is:

This method is implemented by using deferred execution. The immediate return value is an object that stores all the information that is required to perform the action. The query represented by this method is not executed until the object is enumerated either by calling its GetEnumerator method directly or by using foreach in Visual C# or For Each in Visual Basic.

-- int19h (talk) 05:45, 18 July 2008 (UTC)

I do not think dynamic is the correct way to describe this behavior. Rather, I would describe it as parametric. The selection variable in your example does not represent a sequence but rather a process which generates one by enumerating a mutable collection object(in this case an array of integers). Each time the selection variable is enumerated, it generates the resulting sequence by enumerating the current contents of said collection. The query itself is not dynamic so much as the source collection from which it builds its results is mutable. Aluan Haddad (talk) 06:40, 7 May 2014 (UTC)

Pros and cons of Linq

I miss to read pro and cons of linq, currently im searching for information related with linq and as far im found linq produce a performance hit also can break/incompatible with previous oo models. --190.47.241.187 (talk) 18:13, 12 August 2008 (UTC)--190.47.241.187 (talk) 18:13, 12 August 2008 (UTC)

The main con is that Linq for Objects is a huge performance hit, using nested loops all the time. If you want fast execution, use indexes (hashtables or B-trees), if you want ACID use relational DBMS, but Linq for objects gives you neither. It's fine syntactic sugar with currently little to back it up algorithmically. 212.188.109.67 (talk) 21:55, 20 August 2008 (UTC)

I disagree, with the both assertion that LINQ to Objects is simply a syntactic sugar and that it is huge performance hit.

1. LINQ allows many algorithms to be expressed at a higher level of abstraction, and can dramatically improve readability.

2. LINQ queries can often often be parallelized for dramatic performance gains on machines with 4+ logical cores. Additionally, Lazy evaluation can reduce memory consumption and processing requirements. Sure, in some cases it will be slower, but write for readability/maintainability first instead of optimizing prematurely.

3. LINQ to objects complements Linq to SQL etc. by abstracting away the differences in the physical storage of the data. This means that algorithms can be written against a conceptual object model that may come from any arbitrary data provider.

4. Linq to objects is an implementation of the well known higher order functions, map(Select), filter(Where), foldLeft/reduce(Aggregate), flatMap(SelectMany), which are the idiomatic way to process sequences in many languages with higher order functions (see Scala, F#, and Lisp, Dart, JavaScript, etc). The syntax is not the point the point is the functions and the idea of a uniform abstraction of operations over sequences.Aluan Haddad (talk) 04:16, 7 May 2014 (UTC)

If you want to boost performance of your LINQ to Object queries, you may use i4o which can index your in-memory collections: http://www.codeplex.com/i4o --Ondrejsv (talk) 14:16, 5 December 2008 (UTC)

LINQ-TO-XML Syntax Examples

I'm considering adding a LINQ-TO-XML syntax example similar to the one already in-place for the LINQ-TO-SQL. If I added a syntax example which extracted elements from a well known XML document type like RSS 2.0 or Atom 1.0, would this be acceptable? --Omgcapitalism (talk) 18:10, 27 April 2010 (UTC)

Why should it not be acceptable? I'd say, go ahead and add it. Also, as a general rule, don't try to establish consensus beforehand. Be bold. --Daniel5Ko (talk) 17:48, 28 April 2010 (UTC)

Pronunciation

There is some dispute about the pronunciation of 'LINQ'. I just reverted an edit by an anonmyous author which changed the pronunciation from 'link' to 'lin q'. Most of the comments on [[1]] indicate that 'link' is the most common pronunciation, including the one used in Microsoft. Julianhyde (talk) —Preceding undated comment added 22:07, 17 March 2011 (UTC).

Well, I'd say, just listen to Erik Meijer et al. at Channel 9. There's no doubt that the pronounciation is 'link'. And if MS is not the definite source, who else should be? --Daniel5Ko (talk) 00:07, 18 March 2011 (UTC)

Diambiguation

I can think of at least three terms for referencing "linq", this page being one. On that note, I am considering creating a Disambiguation page for this topic.Rajpaj (talk) 13:06, 10 May 2011 (UTC)

It would appear that a disambiguation page was created at some point in time: http://en.wikipedia.org/wiki/Linq

173.13.156.125 (talk) 10:31, 26 May 2015 (UTC)

Laziness

I think a basic description on how LINQ works should not miss which role laziness plays there. — Preceding unsigned comment added by Wikitester2501 (talk • contribs) 10:15, 21 October 2012 (UTC)

Wikipedia:Articles for deletion/Cω merge

This discussion indicated a preference for a very selective merge from Cω to this article. I'd like to get this completed, but this is not my field. If someone could indicate what should be moved over, and (most especially) where it should be placed, I'd be grateful. Pinging @Bearian and Elmidae:, but I'd be happy to hear from anyone with more knowledge than I have (i.e. "just about anyone"). Joyous! | Talk 16:32, 26 February 2023 (UTC)