@brunnerh
Thank you for a counterexample. I agree that with complex queries they probably become more worthwhile, and at some point almost certainly are nicer than using lambdas directly, however, I would argue a complex query should not even be kept in the code, usually.
(I should note, I'm not too familiar with LINQ to SQL)
It can probably be refactored into multiple reusable functions. (and the moment you do this, the LINQ syntax will be worse again) - It probably should be, and using LINQ syntax makes it harder to do so. - At least to me, large queries seem quite hard to read and reason about, whereas 'composing function{s, calls}' is much nicer (I admit, this is probably a matter of opinion, but I often reuse 'subqueries' and that is generally better).
(if it is LINQ to objects) I've never seen that complex queries actually needed - Usually, there is no problem using 'lambda' syntax. (although, to be fair: I haven't always tried, but the trying would probably cost more time overall, than just always using one pattern for everything - especially one that INTERRACTS well with everything else in the language)
(if it is LINQ to SQL) If it is complex enough: it should probably not be written in C# at all, as LINQ syntax is very limiting, and I've repeatedly found it does not support things I needed, and had to rewrite it in raw SQL anyway.
Writing a query that mixes SQL and memory (does not translate to SQL) feels like a code smell to me. I understand there is some benefit to having a purely SQL query, which you then change to actually run in memory, without rewriting it, but it feels more like it would happen by accident, and not behaving as you expect it to. - I like to have a clear separation of what runs where, and generally clear separation between all things that need their own 'governing'.
Lambda noise was never much of an issue for me, but I admit this is a good point. I use lambdas everywhere for everything, but someone not as used to them might find it annoying.
Overall, there probably is some use for them (for actual, complex queries) but in my experience, I don't think I've ever encountered it. I guess they may be great for someone else, I just cannot imagine it...
PS: No idea why dev.to notified me the first time, but not again. I've only found this because I came back to report on my own findings.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
@maartyl here goes me proving you wrong! 😅
But with this argument, we all come out as winners. The abundance of tools means there's more than one way to do the job.
@brunnerh Thank you for a counterexample. I agree that with complex queries they probably become more worthwhile, and at some point almost certainly are nicer than using lambdas directly, however, I would argue a complex query should not even be kept in the code, usually.
(I should note, I'm not too familiar with LINQ to SQL)
It can probably be refactored into multiple reusable functions. (and the moment you do this, the LINQ syntax will be worse again) - It probably should be, and using LINQ syntax makes it harder to do so. - At least to me, large queries seem quite hard to read and reason about, whereas 'composing function{s, calls}' is much nicer (I admit, this is probably a matter of opinion, but I often reuse 'subqueries' and that is generally better).
(if it is LINQ to objects) I've never seen that complex queries actually needed - Usually, there is no problem using 'lambda' syntax. (although, to be fair: I haven't always tried, but the trying would probably cost more time overall, than just always using one pattern for everything - especially one that INTERRACTS well with everything else in the language)
(if it is LINQ to SQL) If it is complex enough: it should probably not be written in C# at all, as LINQ syntax is very limiting, and I've repeatedly found it does not support things I needed, and had to rewrite it in raw SQL anyway.
Writing a query that mixes SQL and memory (does not translate to SQL) feels like a code smell to me. I understand there is some benefit to having a purely SQL query, which you then change to actually run in memory, without rewriting it, but it feels more like it would happen by accident, and not behaving as you expect it to. - I like to have a clear separation of what runs where, and generally clear separation between all things that need their own 'governing'.
Lambda noise was never much of an issue for me, but I admit this is a good point. I use lambdas everywhere for everything, but someone not as used to them might find it annoying.
Overall, there probably is some use for them (for actual, complex queries) but in my experience, I don't think I've ever encountered it. I guess they may be great for someone else, I just cannot imagine it...
PS: No idea why dev.to notified me the first time, but not again. I've only found this because I came back to report on my own findings.