Hacker News Reader

Comment by sedatk | Hacker News Reader

Totally. I couldn't care less if the LINQ syntax had gone tomorrow, but functional composition is so powerful, and easier to maintain too.

View on HN

I would miss it for `let`, and for multiple `from` clauses. These are things that can be done with extension methods and callbacks, just not as elegantly.

`let` is just a .Select(), isn't it?

A `Select` to a tuple or anonymous class which you have to carry around all the way.

If you look at how a LINQ query gets translated to a method chain (e.g. via SharpLab or let Rider/ReSharper rewrite them) you'll notice that multiple `from`s or `let`s can become quite ugly.

To add on to what you wrote, it amazes me the number of developers that don't understand you can use .Select() to construct named object instances. I'm probably using bad terminology, but something like:

    .Select(x => new Employee { Name = x.Name, DepartmentName = x.Department.Name }).ToList();

How do these developers use .Select() then?

Into anonymous types mostly, where you can't pass the type to another method. Example:

    .Select(x => new { Name = x.Name, DepartmentName = x.Department.Name }).ToList();

Same code as I wrote, except capture in an anonymous type. The documentation practically encourages this.

Oh that's convenient, that's for sure.

There are some queries that are actually easier to compose in LINQ syntax than even in SQL. However, like everyone else, I rarely find myself actually using it. Anything really complex is done in pure SQL and everything else is method syntax.

But it is slightly more expressively powerful than SQL and way easier to follow, if you need it, than the method syntax.

Reply on news.ycombinator.com