He should try adding AsParrallel() to the expression. I bet there will be a drastic speed up as long as he has a multi core.
LINQ Ruined My Favorite Interview Question
11–20 of 218 posts
Re: LINQ Ruined My Favorite Interview Question
#12I am a big fan of LINQ but it gives and takes away complexity at the same time. It makes a 'whole class of things that you would have to do with loops' go away. Once you are comfortable with the syntax, it makes code a lot more readable. But you lose track of when and where things are getting executed. For example, it is easy to make something that you intend to execute inside of SQL server run inside of C# code. And…
It's also really easy to shoot yourself with unless you understand everything and think each problem through.
Four killer issues I've seen so far:
We had a major production performance issue which turned out to be a stray ToList which was causing a massive memory ballooning. Didn't get noticed in test as the test cases passed but it hit prod and 2000 users bashed it and tried to allocate 20Mb each causing our cluster to shit a brick.
Null reference exceptions! There are so many dereferencing operations in an average LINQ expression that you really have no idea which one is blowing if it goes pop in production in release config.
People using .Single(...) and getting more or less than one result back. So frustrating.
If you push an IEnumerable over an interface boundary the performance and memory semantics are not preserved and you end up with a leaky abstraction. These are shits to resolve. Example: queries executing inside the view which is outside the transaction scope.
We've had to ban it in some circumstances.
Re: LINQ Ruined My Favorite Interview Question
#13I 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.
Re: LINQ Ruined My Favorite Interview Question
#14Since we're comparing notes, here's the Mathematica version:
Reverse[SortBy[Tally[StringSplit[#]], #[[2]] &]][[;; 10, 1]] &
Re: LINQ Ruined My Favorite Interview Question
#15LINQ tends to get thought of as "database syntax sugar", but it's way more than that. It's C#'s version of the lazy collection operations you find in most functional languages, just given friendlier sqlish names. (IE, "Select" instead of "map" and "Where" instead of "filter") I almost feel a bit gross when I have to write a "foreach" loop at this point, because there's almost always an equivalent way to do it in LINQ…
I do Lazy LINQ, by which I mean I write the looping code with "foreach"es and get it debugged & working, but then allow Resharper to convert it to LINQ if it can. I think this is mostly because I'm still not comfortable with the syntax, and partly because of the set/iterative impedance mismatch that is there. "It's not you, LINQ. It's me."
You would really benefit from learning a functional language (any) to help you roll your own LINQ. Some of Resharpers refactoring to LINQ is awful and does not make for cleaner code.
Re: LINQ Ruined My Favorite Interview Question
#16I hate to be the bearer of bad news, but I think there may be even simpler solutions to this problem: (take 10 (reverse (sort-by (comp first rest) (frequencies (string/split ... #"\+s")))) The above is a Clojure one-liner example that I believe satisfies the original problem. So while LINQ may have simplified from the C-language family solutions he had seen, it's clearly possible to take it one step further with the…
You'll need to sort the result of frequencies: it's an unordered map.
In practice, if you use ->> and write neater LINQ, the code is very close. Although LINQ only has group and sum/reduce, no dedicated frequencies function.
Re: LINQ Ruined My Favorite Interview Question
#17LINQ tends to get thought of as "database syntax sugar", but it's way more than that. It's C#'s version of the lazy collection operations you find in most functional languages, just given friendlier sqlish names. (IE, "Select" instead of "map" and "Where" instead of "filter") I almost feel a bit gross when I have to write a "foreach" loop at this point, because there's almost always an equivalent way to do it in LINQ…
I almost feel a bit gross when I have to write a "foreach" loop at this point
Agreed. I've transitioned to spending most of my time in JS, and wherever I can I use .map(), but the chaining it's not quite the same as LINQ. Someday I intend to write a library of Array addons to provide GroupBy and so on, but I can't imagine it'll be super efficient.
Re: LINQ Ruined My Favorite Interview Question
#18I am a big fan of LINQ but it gives and takes away complexity at the same time. It makes a 'whole class of things that you would have to do with loops' go away. Once you are comfortable with the syntax, it makes code a lot more readable. But you lose track of when and where things are getting executed. For example, it is easy to make something that you intend to execute inside of SQL server run inside of C# code. And…
But you lose track of when and where things are getting executed.
That is the curse of modern software development. But LINQ is minor offender here compared to some kinds of remoting, code reflects from endless xml configs wrapped in gazillion interfaces and some inventive orm-s. Sadly our tools have not kept up with the complexity that is external to the executing code. The debugger in the pre- inversion of control/bean injection days was almighty because you had all of the program state in front of you.
A little known fact is that if you wrap Java/C# code in enough unit tests you get Haskell.
Re: LINQ Ruined My Favorite Interview Question
#19I hate to be the bearer of bad news, but I think there may be even simpler solutions to this problem: (take 10 (reverse (sort-by (comp first rest) (frequencies (string/split ... #"\+s")))) The above is a Clojure one-liner example that I believe satisfies the original problem. So while LINQ may have simplified from the C-language family solutions he had seen, it's clearly possible to take it one step further with the…
Oh, we can use our favorite language in our new job? Here is a Python solution.
from collections import Counter
Counter(s1.split(' ')).most_common(10)Re: LINQ Ruined My Favorite Interview Question
#20I 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.
LINQ is not a magic bullet. It has some serious pitfalls.
I'd like to aee people using the right tools for the job.