YES, I agree, the Lambda version of the LINQ statements (and the 'Method' syntax) to me are less appealing (and NICE) than the 'Simple Syntax' I posted earlier.
There are a number of good reasons for developers sticking to the 'simple syntax' as I have clearly put in my 'ClickStartLINQ' eNotes.
However, since Lambda is used 'under the hood', and also on some rare occasions needs to be used along with the simple syntax, then we do need to know how to do it. I have included these special (or rare) 'Method' occasions in my eNotes. Check out '.Distinct' and 'Reverse'.
Please be aware that some experienced guys like Nick Friend use Lambda extensively and to great effect in their big business apps - he is very used to it. And it does get easier with time and practise.
I have attached an image of a useful and explanatory comment, or two. This has been in my eNotes for over four years.
... >> To help us understand the two syntaxes, here is a quote from the eBook by Pialosi and Russo :-
[ .. their book is "Programming Microsoft LINQ in the .NET Framework"]
So we need Lambda to be there, we need to know the syntax for X# and how to use Lambda when we need to - BUT - we can use the simple (sugary) syntax more on a day to day basis, and this is even less complex than the SQL Server 'T-SQL' code itself. So everyone is a winner really.
Oh! and you can mix the two as well, only using the Lambda bit (on/with the simple syntax code) when there is no alternative.
I like definitively the Lambda expressions and its power in X# - but as with every powerful tool it is very important to not overuse the power to write code that is unmaintainable. Sometimes it will be better to write a method than putting the code in a Lambda expression.
What I personally don't like is LinQ - until now I have not found any application where it simplifies my programming life. But it could be that I'll be convinced in the future - I don't exclude that - "Never say never!".
Your samples are very precious so we can see what is possible to accomplish, but it is everyones decision what to use and what not.
Wolfgang, did you take a look at LinQ in combination with e.g. Entity Framework (or another OR mapper)?
Normally we would write reports in SQL (storedprocedures/functions etc), but Linq makes it easier to write the same business logic as part of the application in stead of separating it in some other not so manageble environment like a dbms.