4 ms·

In my experience, across a wide variety of applications built wide a number of different teams, LINQ has almost always been an anti-pattern. Whenever you inject

In my experience, across a wide variety of applications built wide a number of different teams, LINQ has almost always been an anti-pattern. Whenever you inject a leaky abstraction (as Spolsky would say), things start to go awry. The crimes of grotesque inefficiency I've seen because the magical LINQ is there to shield devs from proper data tiers.

tester756 3y ago
>LINQ has almost always been an anti-pattern You mean "LINQ" as an input for ORM? or LINQ in general? either way this is crazy claim. There's shitton of projects where queries aren't complex and LINQ will make your life saner instead of this stringly typed hell called SQL. Just check what ORM is generating for your queries and if it is a mess then write it manually and you're good to go. This way you get both benefits: sane type system and performance.
- llm_nerd 3y ago
  LINQ in general is a very bad indicator if it isn't very restricted. I don't think it's a crazy claim whatsoever: When LINQ appears littered through code, it usually mean there has been perilously little data access planning, so instead of planning out and centralizing concise, planned, secure, optimized data access avenues, just pretend that LINQ being available everywhere is a solution. Every LINQ-heavy solution I've had the misfortune of using has always, with zero exceptions, been a performance nightmare. And instead of one big function you can just optimize, it is death by a trillion cuts. I get that there are big LINQ advocates. It's convenient. I'm sure there are projects where it is use spectacularly. I've never seen such a project.
  - rjbwork 3y ago
    LINQ is just functional list comprehensions. Do you think that LINQ is only used for EF/LINQ2SQL?
    - eddythompson80 3y ago
      First time I’ve heard that claim was when I had to start working with Go. I was telling someone how much I miss LINQ/functional programming, and he said exactly the same thing “ugh, LINQ is why .NET is so slow”. I was perplexed. Do you even know what LINQ is? How does it make .NET slow? And to the best of knowledge they were comparing JIT startup time to Go’s AOT time. Smh
      - rjbwork 3y ago
        Yeah. The amount of FUD and ignorance out there in the technical world WRT the .NET ecosystem is astounding.
  - useerup 3y ago
    This comment make me question if you really have any experience with LINQ. If you had, you would not make a comment where you seem to think that LINQ is used only for data access. LINQ is (at the most basic level) list comprehensions done better. It is functional programming for the imperative C# programmers. It has the potential to remove most/all loops and make the code more readable in the process.
    - llm_nerd 3y ago
      >This comment make me question if you really have any experience with LINQ The classic fallback. >If you had, you would not make a comment where you seem to think that LINQ is used only for data access. List comprehension is data access. Accessing sets in memory is data access. >If you had, you would not make a comment where you seem to think that LINQ is used only for data access. It has the potential, and almost the certainty, of allowing one to thoroughly shoot themselves in the foot. See without the "magic" of LINQ the grotesqueness of many patterns of data access (which, as previously mentioned, includes in memory structures. Pretty bizarre that anyone actually in this field thinks this only applies to databases, or that only DBs are "data") would lead one to rethink. LINQ is almost always a bad indicator. It is actually a fantastic thing in one off scripts and hack type code, but when it appears in production code, I would say 90%+ of the time it is absolutely gross, but it hides how gross it actually is.
      - tester756 3y ago
        How is this gross then? It is just a slightly slower than e.g fors, so unless this is hot path, then it is basically not relevant meanwhile it improves readability of the code
      - eddythompson80 3y ago
        > LINQ is almost always a bad indicator. It is actually a fantastic thing in one off scripts and hack type code, but when it appears in production code, I would say 90%+ of the time it is absolutely gross, but it hides how gross it actually is. Yeah, you definitely have no idea what LINQ, or an list, even is.
rspeele 3y ago
Absolutely, there are times where programmers try to do way too much in LINQ and don't realize that the query being generated to back up their chain of LINQ operations is a monstrosity of thousands of lines of SQL that will grind the server to a hault. Or the abstraction leaks badly due to the programmer using something EF doesn't know how to translate to SQL, so it ends up loading a much larger dataset and trying to complete the rest of the filtering in memory. As developers get more acclimated to the .NET ecosystem they usually pick up a good spidey sense for what query "shapes" are appropriate to express in LINQ and which are asking for trouble. However, for every one of those awful LINQ queries in a codebase, I think there are 40 to 50 run-of-the-mill queries that make it worthwhile. The biggest win that it delivers over a simpler, "stringier" ORM is the ability to return structured data. I have no problem writing SQL, but processing the results back out of flat rows into objects gets extremely annoying. Say I want to load some Foos with their Bars. If I use straight SQL with a row mapper, I define a type to represent each FooBar row, load a List<FooBarRow> into memory from my simple left join, then I'll have to do a GroupBy in memory on that List to get the actual structure that I want: a list of Foos where each one has its own list of Bars. Notice that I also have to handle the empty-list case specially. var fooBarRows = await connection.QueryAsync<FooBarRow>("select f.FooId, f.Name as FooName, b.BarId, b.Name as BarName from Foos f left join Bars b on b.FooId = f.FooId where whatever"); // re-shape result set manually from flat query results var foos = fooBarRows .GroupBy(fbr => fbr.FooId) .Select(g => new Foo { FooId = g.Key, FooName = g.First().Name, Bars = g.First().BarId == null ? new List<Bar>() : g.Select(b => new Bar { BarId = b.BarId.Value, BarName = b.BarName }).ToList() }); In EF it's just: var foos = await db.Foos.Where(whatever).Include(f => f.Bars).ToListAsync(); Saving that clutter -- both the code and the otherwise useless intermediate FooBarRow type -- really adds up because the apps I write have a zillion queries very much like this. So I'll take the occasional shitty query that has to be tracked down and optimized in exchange.
- tester756 3y ago
  Really really well said. It is weird that people jump into strange extremas when you can just combine best of both worlds.

tester756 3y ago

>LINQ has almost always been an anti-pattern You mean "LINQ" as an input for ORM? or LINQ in general? either way this is crazy claim. There's shitton of projects where queries aren't complex and LINQ will make your life saner instead of this stringly typed hell called SQL. Just check what ORM is generating for your queries and if it is a mess then write it manually and you're good to go. This way you get both benefits: sane type system and performance.

llm_nerd 3y ago
LINQ in general is a very bad indicator if it isn't very restricted. I don't think it's a crazy claim whatsoever: When LINQ appears littered through code, it usually mean there has been perilously little data access planning, so instead of planning out and centralizing concise, planned, secure, optimized data access avenues, just pretend that LINQ being available everywhere is a solution. Every LINQ-heavy solution I've had the misfortune of using has always, with zero exceptions, been a performance nightmare. And instead of one big function you can just optimize, it is death by a trillion cuts. I get that there are big LINQ advocates. It's convenient. I'm sure there are projects where it is use spectacularly. I've never seen such a project.
- rjbwork 3y ago
  LINQ is just functional list comprehensions. Do you think that LINQ is only used for EF/LINQ2SQL?
  - eddythompson80 3y ago
    First time I’ve heard that claim was when I had to start working with Go. I was telling someone how much I miss LINQ/functional programming, and he said exactly the same thing “ugh, LINQ is why .NET is so slow”. I was perplexed. Do you even know what LINQ is? How does it make .NET slow? And to the best of knowledge they were comparing JIT startup time to Go’s AOT time. Smh
    - rjbwork 3y ago
      Yeah. The amount of FUD and ignorance out there in the technical world WRT the .NET ecosystem is astounding.
- useerup 3y ago
  This comment make me question if you really have any experience with LINQ. If you had, you would not make a comment where you seem to think that LINQ is used only for data access. LINQ is (at the most basic level) list comprehensions done better. It is functional programming for the imperative C# programmers. It has the potential to remove most/all loops and make the code more readable in the process.
  - llm_nerd 3y ago
    >This comment make me question if you really have any experience with LINQ The classic fallback. >If you had, you would not make a comment where you seem to think that LINQ is used only for data access. List comprehension is data access. Accessing sets in memory is data access. >If you had, you would not make a comment where you seem to think that LINQ is used only for data access. It has the potential, and almost the certainty, of allowing one to thoroughly shoot themselves in the foot. See without the "magic" of LINQ the grotesqueness of many patterns of data access (which, as previously mentioned, includes in memory structures. Pretty bizarre that anyone actually in this field thinks this only applies to databases, or that only DBs are "data") would lead one to rethink. LINQ is almost always a bad indicator. It is actually a fantastic thing in one off scripts and hack type code, but when it appears in production code, I would say 90%+ of the time it is absolutely gross, but it hides how gross it actually is.
    - tester756 3y ago
      How is this gross then? It is just a slightly slower than e.g fors, so unless this is hot path, then it is basically not relevant meanwhile it improves readability of the code
    - eddythompson80 3y ago
      > LINQ is almost always a bad indicator. It is actually a fantastic thing in one off scripts and hack type code, but when it appears in production code, I would say 90%+ of the time it is absolutely gross, but it hides how gross it actually is. Yeah, you definitely have no idea what LINQ, or an list, even is.

rspeele 3y ago

Absolutely, there are times where programmers try to do way too much in LINQ and don't realize that the query being generated to back up their chain of LINQ operations is a monstrosity of thousands of lines of SQL that will grind the server to a hault. Or the abstraction leaks badly due to the programmer using something EF doesn't know how to translate to SQL, so it ends up loading a much larger dataset and trying to complete the rest of the filtering in memory. As developers get more acclimated to the .NET ecosystem they usually pick up a good spidey sense for what query "shapes" are appropriate to express in LINQ and which are asking for trouble. However, for every one of those awful LINQ queries in a codebase, I think there are 40 to 50 run-of-the-mill queries that make it worthwhile. The biggest win that it delivers over a simpler, "stringier" ORM is the ability to return structured data. I have no problem writing SQL, but processing the results back out of flat rows into objects gets extremely annoying. Say I want to load some Foos with their Bars. If I use straight SQL with a row mapper, I define a type to represent each FooBar row, load a List<FooBarRow> into memory from my simple left join, then I'll have to do a GroupBy in memory on that List to get the actual structure that I want: a list of Foos where each one has its own list of Bars. Notice that I also have to handle the empty-list case specially. var fooBarRows = await connection.QueryAsync<FooBarRow>("select f.FooId, f.Name as FooName, b.BarId, b.Name as BarName from Foos f left join Bars b on b.FooId = f.FooId where whatever"); // re-shape result set manually from flat query results var foos = fooBarRows .GroupBy(fbr => fbr.FooId) .Select(g => new Foo { FooId = g.Key, FooName = g.First().Name, Bars = g.First().BarId == null ? new List<Bar>() : g.Select(b => new Bar { BarId = b.BarId.Value, BarName = b.BarName }).ToList() }); In EF it's just: var foos = await db.Foos.Where(whatever).Include(f => f.Bars).ToListAsync(); Saving that clutter -- both the code and the otherwise useless intermediate FooBarRow type -- really adds up because the apps I write have a zillion queries very much like this. So I'll take the occasional shitty query that has to be tracked down and optimized in exchange.

tester756 3y ago
Really really well said. It is weird that people jump into strange extremas when you can just combine best of both worlds.