Qual è il ragionamento alla base della denominazione di .NETs Select (Map) e Aggregate (Reduce)?

In altri linguaggi di programmazione, ho visto Map and Reduce, e questi sono i cardini della programmazione funzionale. Non sono riuscito a trovare alcun ragionamento o storia per cui LINQ ha Aggregate(lo stesso di Reduce) e Select(lo stesso di Map)?

Perché sto chiedendo è che mi ci è voluto un po 'di tempo per capire che è la stessa cosa e sono curioso di sapere qual è il ragionamento per questo.

Questo dipende principalmente dalla storia di LINQ.

Originariamente LINQ doveva essere simile a SQL e utilizzato (ampiamente, ma non esclusivamente) per connettersi a database SQL. Ciò porta a gran parte della sua terminologia basata su SQL.

Quindi, "selezionare" venuto dal SQL selectdichiarazione, e "aggregato" è venuto da funzioni di aggregazione SQL (ad esempio, count, sum, avg, min, max).

Per coloro che mettono in dubbio il grado in cui LINQ originariamente si riferiva a SQL, farei riferimento (ad esempio) agli articoli di Microsoft su Cω, che era un linguaggio ideato da Microsoft Research, e sembra essere il luogo in cui sono state lavorate la maggior parte delle basi di LINQ prima che fossero aggiunti a C # e .NET.

Ad esempio, considera un articolo MSDN su Cω , che dice:

Operatori di query in Cω

Cω aggiunge due ampie classi di operatori di query al linguaggio C #:
- Operatori basati su XPath per eseguire query sulle variabili membro di un oggetto per nome o per tipo.
- Operatori basati su SQL per l'esecuzione di query sofisticate che coinvolgono proiezione, raggruppamento e unione di dati da uno o più oggetti.

Almeno per quanto ne so, gli operatori basati su XPath non sono mai stati aggiunti a C #, lasciando solo gli operatori documentati (prima che esistesse LINQ) come direttamente basati su SQL.

Ora, è certamente vero che LINQ non è identico agli operatori di query basati su SQL in Cω. In particolare, LINQ segue gli oggetti di base di C # e la sintassi delle chiamate di funzione molto più da vicino di Cω. Le query Cω hanno seguito la sintassi SQL ancora più da vicino, quindi è possibile scrivere qualcosa del genere (di nuovo, disegnato direttamente dall'articolo collegato sopra):

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

E sì, lo stesso articolo parla in particolare dell'utilizzo delle query basate su SQL per eseguire query sui dati provenienti da database SQL effettivi:

Per connettersi a un database SQL in Cω, deve essere esposto come assembly gestito (ovvero un file di libreria .NET), a cui fa riferimento l'applicazione. Un database relazionale può essere esposto a un Cω come assembly gestito utilizzando lo strumento da riga di comando sql2comega.exe o la finestra di dialogo Aggiungi schema database ... da Visual Studio. Gli oggetti di database sono usati da Cω per rappresentare il database relazionale ospitato dal server. Un oggetto Database ha una proprietà pubblica per ogni tabella o vista e un metodo per ogni funzione con valori di tabella presente nel database. Per eseguire una query su un database relazionale, è necessario specificare una tabella, una vista o una funzione con valori di tabella come input per uno o più operatori basati su SQL.

Il seguente programma di esempio e l'output mostrano alcune delle funzionalità dell'utilizzo degli operatori basati su SQL per eseguire query su un database relazionale in Cω. Il database utilizzato in questo esempio è il database Northwind di esempio fornito con Microsoft SQL Server. Il DB nome utilizzato nell'esempio riferisce ad un'istanza globale di un oggetto Database nella Northwind namespace del Northwind.dll assembly generato usando sql2comega.exe .

Quindi sì, sin dall'inizio (o anche prima dell'inizio, a seconda del punto di vista) LINQ era esplicitamente basato su SQL e intendeva specificamente consentire l'accesso ai dati nei database SQL.

Metodi LINQ in .Net

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

sono stati nominati per essere coerenti con la sintassi della query LINQ in C # (e VB.NET)

from x in source
where condition
select projection

che è stato progettato per essere familiare alle persone che conoscono SQL

SELECT projection
FROM source x
WHERE condition

Per me, selezionare e aggregare ha più senso. Man mano che l'entità diventa il metodo dominante per interrogare e manipolare i dati in .Net, Linq viene sempre più utilizzato dagli sviluppatori che probabilmente sono abituati a lavorare con i dati tramite SQL. Quindi, usare parole come "Seleziona" ha più senso per quegli sviluppatori, perché quelle sono le parole chiave a cui sono abituati.