6 ms·

LINQ one of the most beautiful things in C# after extension methods!

corresation 13y ago
I would say that LINQ is one of the worst things to ever happen to .NET. On one team I had to make a dictum that barred LINQ from even being used, except in exceptional circumstances. I do not mean to raise the ire of defensive .NET programmers by saying this: as with most things, used right it is a beautiful thing, and there is nothing fundamentally wrong with LINQ. But what it was used for in practice was almost always grotesquely inefficient. If someone had to make a loop to iterate objects to find a member on every function call, pretty soon they'll realize they should using a System.Collections.Generic.Dictionary for instance, or some other appropriate data structure (e.g. Need sorted data? Then use a sorted tree, for instance). When it's a simple LINQ query, though, it's one seemingly harmless little line, so it tends to get a pass. Pretty soon profiles were just hundreds (if not thousands) of different cases where LINQ was used as a cure-all, destroying performance under any load at all. LINQ is not magical. It is doing the same dirty work that you would be doing yourself if you needed to filter / sort / recast, but provides syntactical sugar to do so. The compiler and runtime will happily generate horrifically inefficient code if you request it, with no warning or complaints. The tldr; is that it is a fantastic set abstraction that is more often than not grossly abused.
- aashishkoirala 13y ago
  I've seen that happen as well, but you can't blame LINQ for that. Shitty developers will make a mess out of any technology.
- louthy 13y ago
  > I would say that LINQ is one of the worst things to ever happen to .NET. On one team I had to make a dictum that barred LINQ from even being used, except in exceptional circumstances. I find it incredible when I see comments like this. What you should have done is instigated a mentoring programme for the programmers who aren't yet up to speed. LINQ is one of the best things to happen to the language and you just go and kill it.
- jmcqk6 13y ago
  I would change this a little bit. LINQ creates much more readable code, which is always a good thing. I think the real problem is Cargo Cult programming. People are using linq (especially in combination with EF) and not understanding what's actually going on. So they end up getting things like n+1 selects on collections with thousands of items. They don't understand delayed evaluation. Or how sorting effects a Where() call. The problem is programmers who think they can take some code from stack overflow and use it without outstanding it. That problem is not unique to LINQ or .NET.
  - corresation 13y ago
    That problem is not unique to LINQ or .NET. It absolutely isn't unique to it -- powerful features allow programmers to shoot themselves in the feet, and this is true since we began this profession. When dealing with larger applications and datasets it has the potential of easily imposing enormous costs, of the sort that absolutely eclipse most other anti-patterns. Appending on an immutable string through recursive function calls suddenly looks like child's play. The truth is that in most apps, these inefficiencies simply don't matter, and to all of the "just learn how to use it right!" replies, I would say that odds favor that those people aren't using it right at all. But in the end it just doesn't matter that much because small amounts of data, low demands, etc, just makes it an irrelevant cost. Most apps are running with an excess of CPU resources relative to the demands on the app, so it just doesn't matter. Many .NET developers have never run Visual Studio's profiler. They don't even know what the costs are, but we're in a world where 1500ms to load a basic form is okay. When you deal with very large scale financial data, as I do, however, your world is a very different world. You don't just have a scrum where you try to teach people that LINQ isn't magic (which of course we did). The risk factors become much higher.
    - louthy 13y ago
      If the milliseconds matter so much then why aren't you using code reviews or unit tests to catch the problem queries? LINQ isn't just about hitting a database either, it enables a more declarative / functional approach to development in general, which brings huge benefits in terms of parallelisation / robustness / testability. It seems absurd that you would block your team from using it. Edit: Oh and btw, you're not the only person who has to deal with "large scale data". Many of us do and manage just fine with LINQ.
- Guillaume86 13y ago
  Sounds like you'd prefer to forbid LINQ than actually teach how to properly use it, IMO it's absurd. LINQ is really one of the best things in .NET. Just like any tool, you need to learn it before using it properly.
- nightski 13y ago
  I think your team is one of the worst things to happen to .NET. No offense, but that sounds like hell.
  - corresation 13y ago
    Oh you entirely intend it to be offensive, which is fine. Believe what you want. I will say again that of the three "I can't believe it!" responses thus far, I'll bet zero have ever even run their profiler. Ignorance, as they say, is bliss, and in many cases is perfectly fine.
    - nightski 13y ago
      I meant offense to your team, not you. Even though I have used profilers such as NHProf or Ants quite extensively in .NET, you hardly need to use one to understand the implications of a Linq statement - particularly an IEnumerable based one. If your team doesn't understand simple concepts like iteration or projection (and allocation) then you have an uphill battle to fight regardless of the tech you choose.
- avenger123 13y ago
  Not all of us using .NET use LINQ without any oversight or thought. It's a great tool and needs to be used wisely. For example, all queries that are generated for database calls via LINQ are reviewed and analyzed to make sure its what is expected. You are right, LINQ is not magical and was never meant to be. I don't think using LINQ is an automatic ticket to leave your brain at the door. In your case, it's easier to blame the tech and stop using it than to take responsibility for training the team to be better developers. I would also imagine that on this team the use of var was also restricted?
- profquail 13y ago
  Counter-argument: maybe by completely banning LINQ you're prematurely optimizing? If you can describe some query or aggregation with LINQ, it may not always be super-fast, but it's also less error-prone than hand-writing equivalent, faster code. It seems like it'd be better to allow the usage of LINQ, at least for the purposes of rapid prototyping and implementing behavioral/unit tests; once you're happy the system works as expected, you can hit it with a performance/memory profiler to identify specific parts of the code which need to be optimized. Also, check out LinqOptimizer -- it analyzes your LINQ queries and can optimize them for better performance (and it's free!): https://github.com/nessos/LinqOptimizer https://github.com/nessos/LinqOptimizer
- phaedrus 13y ago
  Yes but LINQ also provides GroupBy() and ToDictionary() which can be used together to replace Where() or First() in subexpressions and restore performance. Simply banning a useful tool's use altogether just means you weren't any more willing to learn how to use the tool correctly than the programmers who were misusing it.
platz 13y ago
Extension methods aren't so great. Odersky resisted putting them into Scala and they went for implicits instead.

I would say that LINQ is one of the worst things to ever happen to .NET. On one team I had to make a dictum that barred LINQ from even being used, except in exceptional circumstances. I do not mean to raise the ire of defensive .NET programmers by saying this: as with most things, used right it is a beautiful thing, and there is nothing fundamentally wrong with LINQ. But what it was used for in practice was almost always grotesquely inefficient. If someone had to make a loop to iterate objects to find a member on every function call, pretty soon they'll realize they should using a System.Collections.Generic.Dictionary for instance, or some other appropriate data structure (e.g. Need sorted data? Then use a sorted tree, for instance). When it's a simple LINQ query, though, it's one seemingly harmless little line, so it tends to get a pass. Pretty soon profiles were just hundreds (if not thousands) of different cases where LINQ was used as a cure-all, destroying performance under any load at all. LINQ is not magical. It is doing the same dirty work that you would be doing yourself if you needed to filter / sort / recast, but provides syntactical sugar to do so. The compiler and runtime will happily generate horrifically inefficient code if you request it, with no warning or complaints. The tldr; is that it is a fantastic set abstraction that is more often than not grossly abused.

aashishkoirala 13y ago
I've seen that happen as well, but you can't blame LINQ for that. Shitty developers will make a mess out of any technology.
louthy 13y ago
> I would say that LINQ is one of the worst things to ever happen to .NET. On one team I had to make a dictum that barred LINQ from even being used, except in exceptional circumstances. I find it incredible when I see comments like this. What you should have done is instigated a mentoring programme for the programmers who aren't yet up to speed. LINQ is one of the best things to happen to the language and you just go and kill it.
jmcqk6 13y ago
I would change this a little bit. LINQ creates much more readable code, which is always a good thing. I think the real problem is Cargo Cult programming. People are using linq (especially in combination with EF) and not understanding what's actually going on. So they end up getting things like n+1 selects on collections with thousands of items. They don't understand delayed evaluation. Or how sorting effects a Where() call. The problem is programmers who think they can take some code from stack overflow and use it without outstanding it. That problem is not unique to LINQ or .NET.
- corresation 13y ago
  That problem is not unique to LINQ or .NET. It absolutely isn't unique to it -- powerful features allow programmers to shoot themselves in the feet, and this is true since we began this profession. When dealing with larger applications and datasets it has the potential of easily imposing enormous costs, of the sort that absolutely eclipse most other anti-patterns. Appending on an immutable string through recursive function calls suddenly looks like child's play. The truth is that in most apps, these inefficiencies simply don't matter, and to all of the "just learn how to use it right!" replies, I would say that odds favor that those people aren't using it right at all. But in the end it just doesn't matter that much because small amounts of data, low demands, etc, just makes it an irrelevant cost. Most apps are running with an excess of CPU resources relative to the demands on the app, so it just doesn't matter. Many .NET developers have never run Visual Studio's profiler. They don't even know what the costs are, but we're in a world where 1500ms to load a basic form is okay. When you deal with very large scale financial data, as I do, however, your world is a very different world. You don't just have a scrum where you try to teach people that LINQ isn't magic (which of course we did). The risk factors become much higher.
  - louthy 13y ago
    If the milliseconds matter so much then why aren't you using code reviews or unit tests to catch the problem queries? LINQ isn't just about hitting a database either, it enables a more declarative / functional approach to development in general, which brings huge benefits in terms of parallelisation / robustness / testability. It seems absurd that you would block your team from using it. Edit: Oh and btw, you're not the only person who has to deal with "large scale data". Many of us do and manage just fine with LINQ.
Guillaume86 13y ago
Sounds like you'd prefer to forbid LINQ than actually teach how to properly use it, IMO it's absurd. LINQ is really one of the best things in .NET. Just like any tool, you need to learn it before using it properly.
nightski 13y ago
I think your team is one of the worst things to happen to .NET. No offense, but that sounds like hell.
- corresation 13y ago
  Oh you entirely intend it to be offensive, which is fine. Believe what you want. I will say again that of the three "I can't believe it!" responses thus far, I'll bet zero have ever even run their profiler. Ignorance, as they say, is bliss, and in many cases is perfectly fine.
  - nightski 13y ago
    I meant offense to your team, not you. Even though I have used profilers such as NHProf or Ants quite extensively in .NET, you hardly need to use one to understand the implications of a Linq statement - particularly an IEnumerable based one. If your team doesn't understand simple concepts like iteration or projection (and allocation) then you have an uphill battle to fight regardless of the tech you choose.
avenger123 13y ago
Not all of us using .NET use LINQ without any oversight or thought. It's a great tool and needs to be used wisely. For example, all queries that are generated for database calls via LINQ are reviewed and analyzed to make sure its what is expected. You are right, LINQ is not magical and was never meant to be. I don't think using LINQ is an automatic ticket to leave your brain at the door. In your case, it's easier to blame the tech and stop using it than to take responsibility for training the team to be better developers. I would also imagine that on this team the use of var was also restricted?
profquail 13y ago
Counter-argument: maybe by completely banning LINQ you're prematurely optimizing? If you can describe some query or aggregation with LINQ, it may not always be super-fast, but it's also less error-prone than hand-writing equivalent, faster code. It seems like it'd be better to allow the usage of LINQ, at least for the purposes of rapid prototyping and implementing behavioral/unit tests; once you're happy the system works as expected, you can hit it with a performance/memory profiler to identify specific parts of the code which need to be optimized. Also, check out LinqOptimizer -- it analyzes your LINQ queries and can optimize them for better performance (and it's free!): https://github.com/nessos/LinqOptimizer https://github.com/nessos/LinqOptimizer
phaedrus 13y ago
Yes but LINQ also provides GroupBy() and ToDictionary() which can be used together to replace Where() or First() in subexpressions and restore performance. Simply banning a useful tool's use altogether just means you weren't any more willing to learn how to use the tool correctly than the programmers who were misusing it.

platz 13y ago

Extension methods aren't so great. Odersky resisted putting them into Scala and they went for implicits instead.