[deleted]
LINQ Ruined My Favorite Interview Question
51–60 of 218 posts
Re: LINQ Ruined My Favorite Interview Question
#52> “Return the top 10 most frequently occurring words in a string.” ... > var words = s1.Split(' '); Wrong. Yet another example where an interviewer cannot correctly solve his own questions.
Care to elaborate? It probably lacks punctuation characters, case-insensitiveness and RemoveEmptyItems option, but is there anything else missing?
Re: LINQ Ruined My Favorite Interview Question
#53I 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.
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.
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.
Re: LINQ Ruined My Favorite Interview Question
#54The interviewer doesn't see the difference between the LINQ and extension methods and he hasn't provided a single line of LINQ in his post.
Re: LINQ Ruined My Favorite Interview Question
#55I 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.
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 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.
Re: LINQ Ruined My Favorite Interview Question
#56LINQ does make C# more readable but it doesn't add much value over normal functional collections which usually end up more concise, simpler and easier to reason about - visible in my Dart port of C#'s 101 LINQ samples (which are also lazy): https://github.com/dartist/101LinqSamples
performance of Linq 2 Objects is not that great either and it doesn't add much value readability-wise over rewriting the same task in other dynamic languages: https://github.com/dartist/sudoku_solver
Re: LINQ Ruined My Favorite Interview Question
#57> “Return the top 10 most frequently occurring words in a string.” ... > var words = s1.Split(' '); Wrong. Yet another example where an interviewer cannot correctly solve his own questions.
Care to elaborate? It probably lacks punctuation characters, case-insensitiveness and RemoveEmptyItems option, but is there anything else missing?
中国四分之一地区六亿人受雾霾影响 contains more than one word.
Re: LINQ Ruined My Favorite Interview Question
#58I 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…
expressivity of modern languages like Clojure Uh, no. Your solution just uses a bunch of standard library functions (at least, I hope they're not syntactic forms… and why a function as specific as "frequencies" not in some namespace boggles my mind). I could write that in C with an appropriate standard library. Ironically, expressing this in something like SQL actually speaks to the expressivity of the language becau…
That may be true, but it's still a pretty idiomatic Clojure solution. Ask 10 Clojure programmers to solve this problem and most of them will come up with something similar. Ask 10 C programmers and they will likely come back with a program much more similar to the one in the post.
The fact that such functions are at a Clojure programmer's fingertips is exceptionally important. If you strip out the core functions (and macros) from any lisp or Clojure you are left with almost nothing( see http://stackoverflow.com/questions/3482389/how-many-primitiv...).
Re: LINQ Ruined My Favorite Interview Question
#59I think the analysis may've been skewed by the outlying points. They are almost certainly "high leverage points"[1] and so possibly exert an undue influence on the final trend lines.
Re: LINQ Ruined My Favorite Interview Question
#60I 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/…
> A little known fact is that if you wrap Java/C# code in enough unit tests you get Haskell.
It is enough to make you want to switch to a pure message passing system, isn't it?