21

In other programming languages, I have seen Map and Reduce, and those are cornerstones of functional programming. I could not find any reasoning or history why LINQ has Aggregate (same as Reduce) and Select (same as Map)?

Why I am asking is that it took me a while to understand it is the same thing and I am curious what is the reasoning for this.

3

3 Answers 3

34

This mostly comes down to the history of LINQ.

LINQ was originally intended to be SQL-like, and used (largely, though not exclusively) to connect to SQL databases. This leads to much of its terminology being based on SQL.

So, "select" came from the SQL select statement, and "aggregate" came from SQL aggregate functions (e.g., count, sum, avg, min, max).

For those who question the degree to which LINQ originally related to SQL, I'd refer to (for example) Microsoft's articles on Cω, which was a language devised by Microsoft Research, and appears to be where most of the basics of LINQ were worked out before they were added to C# and .NET.

For example, consider an MSDN article on Cω, which says:

Query Operators in Cω

Cω adds two broad classes of query operators to the C# language:
- XPath-based operators for querying the member variables of an object by name or by type.
- SQL-based operators for performing sophisticated queries involving projection, grouping, and joining of data from one or more objects.

At least as far as I know, the XPath-based operators were never added to C#, leaving only the operators that were documented (before LINQ existed) as being based directly on SQL.

Now, it's certainly true that LINQ isn't identical to the SQL-based query operators in Cω. In particular, LINQ follows C#'s basic objects and function calls syntax much more closely than Cω did. Cω queries followed SQL syntax even more closely, so you could write something like this (again, drawn directly from the article linked above):

 rows = select c.ContactName, o.ShippedDate
      from c in DB.Customers
      inner join o in DB.Orders
      on c.CustomerID == o.CustomerID;

And yes, the same article does talk specifically about using the SQL-based queries to query data coming from actual SQL databases:

To connect to a SQL database in Cω, it must be exposed as a managed assembly (that is, a .NET library file), which is then referenced by the application. A relational database can be exposed to a Cω as a managed assembly either by using the sql2comega.exe command line tool or the Add Database Schema... dialog from within Visual Studio. Database objects are used by Cω to represent the relational database hosted by the server. A Database object has a public property for each table or view, and a method for each table-valued function found in the database. To query a relational database, a table, view, or table-valued function must be specified as input to the one or more of the SQL-based operators.

The following sample program and output shows some of the capabilities of using the SQL-based operators to query a relational database in Cω. The database used in this example is the sample Northwind database that comes with Microsoft SQL Server. The name DB used in the example refers to a global instance of a Database object in the Northwind namespace of the Northwind.dll assembly generated using sql2comega.exe.

So, yes, from the very beginning (or even before the beginning, depending on your viewpoint) LINQ was explicitly based on SQL, and intended specifically to allow access to data in SQL databases.

6
  • 5
    I disagree that LINQ was invented for SQL queries. LINQ is based on the query operations in , which in turn inherited them from X♯, which is based on an old Haskell paper. Note that one of the authors of said Haskell papers is Erik Meijer, who was also involved in the design of X♯ and Cω after that, and is of course the designer of LINQ. And it was clear from the very beginning that LINQ could be used to query all sorts of things, not just SQL (it shipped with LINQ-to-SQL, LINQ-to-XML, and LINQ-to-Objects from day 1, shortly followed by … Feb 24, 2016 at 20:57
  • 4
    LINQ-to-Entities), and in fact for a lot more than querying (it's basically general Monad Comprehension syntax). It was designed for familiarity to SQL (and XQuery) programmers, but certainly not limited to that. In a similar vein, Scala's Monad Comprehensions look like for loops, and Haskell's look like C-style imperative code blocks, and so Scala calls its monadic operation flatMap, and Haskell calls it return for the same reason: to fit in with the "illusion" prevented to (former) imperative programmers. Feb 24, 2016 at 21:03
  • 2
    @JörgWMittag: See edited answer. I believe that Microsoft's documentation supports my statements. Feb 24, 2016 at 21:26
  • 3
    +1 for actually justifying the answer instead of wishy-washy guessing. You can't get much more authoritative source than Microsoft themselves. Feb 25, 2016 at 2:06
  • Thank you, fine sir! This is exactly the kind of answer I was hoping to receive.
    – Tx3
    Feb 25, 2016 at 13:09
8

LINQ methods in .Net

source.Where(x => condition)
      .Select(x => projection)

were named to be consistent with LINQ query syntax in C# (and VB.NET)

from x in source
where condition
select projection

which was designed to be familiar to people who know SQL

SELECT projection
FROM source x
WHERE condition
2

To me, Select and Aggregate makes more sense. As entity becomes the dominant method for querying and manipulating data in .Net, Linq is being used more and more by developers who are probably used to working with data through SQL. So, using words like "Select" makes more sense for those developers, because those are the keywords they're used to.

2
  • 4
    "more and more by developers who are probably used to working with data through SQL" I doubt this. The guy I work with who sings the praises of Entity Framework couldn't figure out he needed to do a single INNER JOIN one day when Entity Framework wasn't an option. Probably quite the opposite. More and more people use LINQ everyday who actively avoid writing SQL. People who are comfortable in SQL probably just do more in SQL.
    – jpmc26
    Feb 25, 2016 at 4:23
  • 1
    That's not what I've seen. Mainly what I'm finding (through my recent job search) is that developers who once worked with data using Stored Procedures are starting to do all their scripting in the controller. For me, it helps that Linq uses familiar expressions. I don't doubt that's the case for "the guy you work with," but that's not my experience.
    – Christine
    Feb 25, 2016 at 16:40

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.