Linq brings back lisp memories

Often when I am searching for the most succinct way to write logic, I find myself using a declarative syntax:

public  ExecutionOutcome GetValidationMessages()
       {
           IEnumerable<ExecutionOutcome> failedExecutionOutcomes = Context.ItemGroups
               .Where(x=>x.IsValid==false)
               .Select(x=>ExecutionOutcome.CreateFailureOutcome(
                       string.Format(
                                                        "...",
                                                        x.ItemGroupName
                       )
                   )  
               );
           if(failedExecutionOutcomes.Count()>0)
           {
               return ExecutionOutcome.CreateFailureOutcome(failedExecutionOutcomes.Aggregate(string.Empty, (x,y) => x += y.Message + System.Environment.NewLine));
           }
           return ExecutionOutcome.CreateSuccessfulOutcome();
       }

Thats relatively "cutting edge" the C# crew, but its language concept is about as old as the hills. Here is the ballpark equivalent in LISP, a language concieved in the late 50's.

(apply
 (GetMessage '#),
 (mapcar
  (lambda (x)
   (if (IsValid x)
    nil,
    (CreateExecutionFailureOutcome("..." (ItemGroupName x))),
   )
  ),
  (ItemGroups Context)
 )
)

Lisp was a little on the cryptic side, but its true power was its declarative syntax. Lisp is a "functional language".

C# is a sequential language, with declarative extensions. Linq gives me the ability to jump in and out of "functional language" mode in C#. I find myself gradually turning back into a LISP programmer :)

One thing I wish I could do is take this kind of declarative power and apply it to SQL query plans, now that would impress me.