6 ms·

I hate to be the arrogant know it all on Hacker News, but seriously, if you're writing c# and not using LINQ all the time, you need to catch up. I'm tired of s

by moomin 13y ago

I hate to be the arrogant know it all on Hacker News, but seriously, if you're writing c# and not using LINQ all the time, you need to catch up. I'm tired of seeing people answer interview questions with anything _other_ than LINQ.

kryten 13y ago
LINQ is not a magic bullet. It has some serious pitfalls. I'd like to aee people using the right tools for the job.
- teh_klev 13y ago
  LINQ is a great mechanism for expressing complex operations in a succinct manner. Sure, LINQ may not be a magic bullet and can be abused, but you know the old adage about premature optimisation. Perhaps you could elaborate on "It has some serious pitfalls.".
  - hvidgaard 13y ago
    I didn't write the post you responded to, but I can tell you of the main pit fall I have encountered. By far the worst is evaluating the same enumerable again and again by mistake. It don't show up in unittests because they use small data sets, but as soon as you do any kind of load test or put it into production it's painfully slow. The solution is often very simple, but you really have to get dirt on your hands before you recognize where it is a problem.
  - kryten 13y ago
    See https://news.ycombinator.com/item?id=6026280 https://news.ycombinator.com/item?id=6026280
redact207 13y ago
I wouldn't call you arrogant, LINQ has been around for 5 years now and any C# interview should include it. That said, not all questions are best solved with it, but it certainly has made working with enumerables much easier.
apalmer 13y ago
I dont really agree with your statement, but I did find it perplexing that a C# .Net technical interviewer would not know the fundamentals of LINQ 5 years after its inception.
- jameshart 13y ago
  Time flies when you're building stuff, I know, but LINQ was actually announced at PDC 2005 - 8 years ago this fall. That a C# developer can seriously say they're not up to speed with "new stuff" like LINQ (2005) and dynamic (2008) in 2013 is kind of ridiculous. What they mean is that they figured out how to map what they learned about Java in school into C#'s syntax and now they're done learning.
corresation 13y ago
but seriously, if you're writing c# and not using LINQ all the time You don't sound arrogant, but rather sound naive. I agree that someone who recruits surely should have known about and have experienced LINQ significantly by now, but the notion that you should be using it "all the time" is absolute nonsense. I avoid LINQ. I encourage others to avoid LINQ. It is almost always a sign of bad code. LINQ is syntactical sugar over basic set operations. It is perfectly fine if you're doing naive activities, such as the example give -- a contrived example of brute forcing a problem, where two approaches of the same very basic need unsurprisingly yield the same complexity -- but it falls apart in real-world persistent code with considered algorithms and storage. In real long term code, it is usually the canary in the mineshaft telling you that the developers aren't using proper algorithms or storage. In many large-scale projects it invariably turns into the performance nightmare that ends up causing whole rewrites. Again, not because of LINQ itself, which of course can do basic operations like grouping and sorting as quickly as you could do "by hand", but that it makes it so easy to do those things that developers start to resort to that as a catch-all magical solution that is costless because how much could a line or two of code cost? -- a master List<stuff> that they just sort and group by and select from all over the code (O(n) * O(n) * O(n)...why not?). The end result is that the data structures and encapsulation that should have happened never did, so while it might seem more concise and obvious on a one-to-one comparison with a loop perspective, neither case should ever have happened. LINQ is the gun by which a lot of terrible programmers are repeatedly shooting themselves in the foot with, all while gloating about their concise code.
- prospero 13y ago
  Wouldn't it be (O(n) + O(n) + ...) at the worst? And if it's on lazy sequences, which I thought it was, then composing a .Select and an .Aggregate should only involve a single pass through the sequence.
  - corresation 13y ago
    I'm not talking about individual LINQ queries, which themselves can be perfectly fine: Microsoft is pretty smart, so if you're doing basic LINQ for objects grouping and sorting and selecting, they're going to use decent algorithms given the structures used. There is nothing surprising that the submitted usage shows very similar performance, as in the end both cases are doing essentially the same thing. The problem is that it makes it so conveniently easy to do brute-force tactics that....oh the horrible things I've seen...code gets littered with LINQ doing naive queries repeatedly over massive sets of data. Of course you need good coders and good code audits, but LINQ, I think, gives a unsupported sense of comfort that one is making good code (where if people had to code these as loops, it would become very evident very early on that maybe they should rethink their approach).
hackinthebochs 13y ago
I disagree, but for different reasons than the other commenter. LINQ is great for transformations that are intuitively described by the verbs LINQ provides. If your transformation is most easily understood as a process of mapping filtering grouping selecting etc, then by all means. But trying to pigeonhole every iterative process into LINQ is a recipe for code that's hard to decipher. As always its a question of how does one communicate a process most effectively. Succinctness for its own sake is a fools errand. Clarity is key, and sometimes that means foregoing LINQ for standard iteration.
scrabble 13y ago
I answered a phone interview question once with LINQ -- it was about combining string arrays while avoiding duplicates. The HR interviewer followed up my answer asking about runtime and memory usage. While these are good questions, I got the feeling they didn't want to receive an answer using a single line of LINQ.
- gohrt 13y ago
  Do you know the runtime and memory usage of a LINQ query? That's sort of a complication of LINQ.
Chanel_Bunnell 13y ago
The Linq answer is fine for an academic exercise, but it doesn't handle any of the myriad edge cases that pop up when such functionality meets a live product with actual users. I say this as someone who has built a 'word counter' as part of a commercial product. We tried Linq, but had to abandon it due to speed issues as well the sheer number of edge cases. "var words = s.Split(' ');" Example edge case: Words separated by an em, en, or ordinary dash. In the first and second cases, they're two words, in the third, a single word. The basic Split by space function is insufficient for all but the most basic interpretation of a 'word'. In terms of speed, that 20% becomes significant when you're processing millions of words, not a short Wikipedia article. Expand the 'word counter' function to become a unique 'phrase counter' and you have to toss Linq out the window.

by moomin 13y ago

kryten 13y ago

LINQ is not a magic bullet. It has some serious pitfalls. I'd like to aee people using the right tools for the job.

teh_klev 13y ago
LINQ is a great mechanism for expressing complex operations in a succinct manner. Sure, LINQ may not be a magic bullet and can be abused, but you know the old adage about premature optimisation. Perhaps you could elaborate on "It has some serious pitfalls.".
- hvidgaard 13y ago
  I didn't write the post you responded to, but I can tell you of the main pit fall I have encountered. By far the worst is evaluating the same enumerable again and again by mistake. It don't show up in unittests because they use small data sets, but as soon as you do any kind of load test or put it into production it's painfully slow. The solution is often very simple, but you really have to get dirt on your hands before you recognize where it is a problem.
- kryten 13y ago
  See https://news.ycombinator.com/item?id=6026280 https://news.ycombinator.com/item?id=6026280

redact207 13y ago

I wouldn't call you arrogant, LINQ has been around for 5 years now and any C# interview should include it. That said, not all questions are best solved with it, but it certainly has made working with enumerables much easier.

apalmer 13y ago

I dont really agree with your statement, but I did find it perplexing that a C# .Net technical interviewer would not know the fundamentals of LINQ 5 years after its inception.

jameshart 13y ago
Time flies when you're building stuff, I know, but LINQ was actually announced at PDC 2005 - 8 years ago this fall. That a C# developer can seriously say they're not up to speed with "new stuff" like LINQ (2005) and dynamic (2008) in 2013 is kind of ridiculous. What they mean is that they figured out how to map what they learned about Java in school into C#'s syntax and now they're done learning.

corresation 13y ago

but seriously, if you're writing c# and not using LINQ all the time You don't sound arrogant, but rather sound naive. I agree that someone who recruits surely should have known about and have experienced LINQ significantly by now, but the notion that you should be using it "all the time" is absolute nonsense. I avoid LINQ. I encourage others to avoid LINQ. It is almost always a sign of bad code. LINQ is syntactical sugar over basic set operations. It is perfectly fine if you're doing naive activities, such as the example give -- a contrived example of brute forcing a problem, where two approaches of the same very basic need unsurprisingly yield the same complexity -- but it falls apart in real-world persistent code with considered algorithms and storage. In real long term code, it is usually the canary in the mineshaft telling you that the developers aren't using proper algorithms or storage. In many large-scale projects it invariably turns into the performance nightmare that ends up causing whole rewrites. Again, not because of LINQ itself, which of course can do basic operations like grouping and sorting as quickly as you could do "by hand", but that it makes it so easy to do those things that developers start to resort to that as a catch-all magical solution that is costless because how much could a line or two of code cost? -- a master List<stuff> that they just sort and group by and select from all over the code (O(n) * O(n) * O(n)...why not?). The end result is that the data structures and encapsulation that should have happened never did, so while it might seem more concise and obvious on a one-to-one comparison with a loop perspective, neither case should ever have happened. LINQ is the gun by which a lot of terrible programmers are repeatedly shooting themselves in the foot with, all while gloating about their concise code.

prospero 13y ago
Wouldn't it be (O(n) + O(n) + ...) at the worst? And if it's on lazy sequences, which I thought it was, then composing a .Select and an .Aggregate should only involve a single pass through the sequence.
- corresation 13y ago
  I'm not talking about individual LINQ queries, which themselves can be perfectly fine: Microsoft is pretty smart, so if you're doing basic LINQ for objects grouping and sorting and selecting, they're going to use decent algorithms given the structures used. There is nothing surprising that the submitted usage shows very similar performance, as in the end both cases are doing essentially the same thing. The problem is that it makes it so conveniently easy to do brute-force tactics that....oh the horrible things I've seen...code gets littered with LINQ doing naive queries repeatedly over massive sets of data. Of course you need good coders and good code audits, but LINQ, I think, gives a unsupported sense of comfort that one is making good code (where if people had to code these as loops, it would become very evident very early on that maybe they should rethink their approach).

hackinthebochs 13y ago

I disagree, but for different reasons than the other commenter. LINQ is great for transformations that are intuitively described by the verbs LINQ provides. If your transformation is most easily understood as a process of mapping filtering grouping selecting etc, then by all means. But trying to pigeonhole every iterative process into LINQ is a recipe for code that's hard to decipher. As always its a question of how does one communicate a process most effectively. Succinctness for its own sake is a fools errand. Clarity is key, and sometimes that means foregoing LINQ for standard iteration.

scrabble 13y ago

I answered a phone interview question once with LINQ -- it was about combining string arrays while avoiding duplicates. The HR interviewer followed up my answer asking about runtime and memory usage. While these are good questions, I got the feeling they didn't want to receive an answer using a single line of LINQ.

gohrt 13y ago
Do you know the runtime and memory usage of a LINQ query? That's sort of a complication of LINQ.

Chanel_Bunnell 13y ago

The Linq answer is fine for an academic exercise, but it doesn't handle any of the myriad edge cases that pop up when such functionality meets a live product with actual users. I say this as someone who has built a 'word counter' as part of a commercial product. We tried Linq, but had to abandon it due to speed issues as well the sheer number of edge cases. "var words = s.Split(' ');" Example edge case: Words separated by an em, en, or ordinary dash. In the first and second cases, they're two words, in the third, a single word. The basic Split by space function is insufficient for all but the most basic interpretation of a 'word'. In terms of speed, that 20% becomes significant when you're processing millions of words, not a short Wikipedia article. Expand the 'word counter' function to become a unique 'phrase counter' and you have to toss Linq out the window.