←back to thread

201 points olvy0 | 1 comments | | HN request time: 0s | source
Show context
olvy0 ◴[] No.41879131[source]
For me, the most useful part of LINQ is neither the IQueryable syntax tree based extension mechanism, nor the language integrated part (which I dislike), but simply the IEnumerable extensions. Originally known somewhat confusingly as linq to objects. Those allow me to write c# in functional style, keeping the code concise.

The post I submitted refers mostly to optimizations to those extension methods.

This clicked for me after having learned Haskell. It also shares some of Haskell's features/pitfalls, such as laziness.

There are pitfalls, sure, and honestly I wouldn't advise a team having no one somewhat experienced with basic functional idioms (including laziness) to use it. It can lead to obtuse and slow code if used indiscriminately. I try to lead by example myself.

replies(6): >>41879608 #>>41879713 #>>41882332 #>>41882614 #>>41883044 #>>41883519 #
1. progmetaldev ◴[] No.41883519[source]
I've only ever used the method syntax for LINQ. I'm not a fan of having another "embedded" language inside my host language, especially since what is returned eventually needs to go back to C#. When I'm not using an ORM like Entity Framework or Dapper, I still prefer to place my data access logic with SQL into a separate abstracted project so it doesn't spill across my application (and can be replaced if I were to require a different RDBMS, although this has only happened to me once in 20 years).

For more junior devs using LINQ, setting them up with a profiler and the debugger I believe helps makes more sense about what is going on behind the scenes. Sometimes it's helpful to have them code using for-loops and standard C# logic, and then compare to how you'd implement in LINQ, to see the positive and negative of both approaches.