Qual é o motivo por trás da nomeação do .NETs Select (Map) e Agregate (Reduce)?

Em outras linguagens de programação, vi Map and Reduce, e esses são os pilares da programação funcional. Não foi possível encontrar nenhum raciocínio ou histórico por que o LINQ tem Aggregate(o mesmo que Reduce) e Select(o mesmo que Map)?

Por que estou perguntando é que demorei um pouco para entender que é a mesma coisa e estou curioso para saber qual é o motivo disso.

Isso se resume principalmente à história do LINQ.

O LINQ foi originalmente projetado para ser semelhante ao SQL e usado (amplamente, embora não exclusivamente) para conectar-se aos bancos de dados SQL. Isso faz com que grande parte de sua terminologia seja baseada em SQL.

Assim, "select" veio do SQL selectdeclaração, e "agregado" veio de funções agregadas SQL (por exemplo, count, sum, avg, min, max).

Para aqueles que questionam o grau em que o LINQ originalmente se relacionava com o SQL, eu me referiria (por exemplo) aos artigos da Microsoft sobre Cω, que foi uma linguagem criada pela Microsoft Research, e parece ser o local onde a maioria dos conceitos básicos do LINQ foram trabalhados. antes de serem adicionados ao C # e .NET.

Por exemplo, considere um artigo do MSDN sobre Cω , que diz:

Operadores de consulta em Cω

O Cω adiciona duas classes amplas de operadores de consulta à linguagem C #:
- Operadores baseados em XPath para consultar as variáveis ​​de membro de um objeto por nome ou por tipo.
- Operadores baseados em SQL para executar consultas sofisticadas envolvendo projeção, agrupamento e junção de dados de um ou mais objetos.

Pelo menos até onde eu sei, os operadores baseados em XPath nunca foram adicionados ao C #, deixando apenas os operadores documentados (antes da existência do LINQ) como baseados diretamente no SQL.

Agora, certamente é verdade que o LINQ não é idêntico aos operadores de consulta baseados em SQL no Cω. Em particular, o LINQ segue os objetos básicos do C # e a sintaxe das chamadas de função muito mais de perto do que o Cω. As consultas Cω seguiram a sintaxe SQL ainda mais de perto, para que você pudesse escrever algo assim (novamente, extraído diretamente do artigo vinculado acima):

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

E sim, o mesmo artigo fala especificamente sobre o uso de consultas baseadas em SQL para consultar dados provenientes de bancos de dados SQL reais:

Para conectar-se a um banco de dados SQL em Cω, ele deve ser exposto como um assembly gerenciado (ou seja, um arquivo de biblioteca .NET), que é referenciado pelo aplicativo. Um banco de dados relacional pode ser exposto a um Cω como um assembly gerenciado usando a ferramenta de linha de comando sql2comega.exe ou a caixa de diálogo Adicionar esquema do banco de dados ... no Visual Studio. Os objetos de banco de dados são usados ​​por Cω para representar o banco de dados relacional hospedado pelo servidor. Um objeto Database possui uma propriedade pública para cada tabela ou exibição, e um método para cada função com valor de tabela encontrada no banco de dados. Para consultar um banco de dados relacional, uma tabela, exibição ou função com valor de tabela deve ser especificada como entrada para um ou mais operadores baseados em SQL.

O seguinte exemplo de programa e saída mostra alguns dos recursos do uso de operadores baseados em SQL para consultar um banco de dados relacional em Cω. O banco de dados usado neste exemplo é o banco de dados Northwind de exemplo que acompanha o Microsoft SQL Server. O DB nome utilizado no exemplo refere-se a uma instância global de um objecto de dados no Adamastor espaço de nomes do Northwind.dll conjunto gerado usando sql2comega.exe .

Portanto, sim, desde o início (ou mesmo antes do início, dependendo do seu ponto de vista), o LINQ era explicitamente baseado em SQL e pretendia especificamente permitir o acesso a dados em bancos de dados SQL.

Métodos LINQ em .Net

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

foram nomeados para serem consistentes com a sintaxe da consulta LINQ em C # (e VB.NET)

from x in source
where condition
select projection

que foi projetado para ser familiar para pessoas que conhecem SQL

SELECT projection
FROM source x
WHERE condition

Para mim, Selecionar e Agregar faz mais sentido. À medida que a entidade se torna o método dominante para consultar e manipular dados no .Net, o Linq está sendo usado cada vez mais por desenvolvedores que provavelmente estão acostumados a trabalhar com dados por meio do SQL. Portanto, usar palavras como "Selecionar" faz mais sentido para esses desenvolvedores, porque essas são as palavras-chave às quais estão acostumadas.