Live data from Hacker News

LINQ Ruined My Favorite Interview Question

scottchamberlin.tumblr.com

61–70 of 218 posts

Re: LINQ Ruined My Favorite Interview Question

#61
The biggest benefit I find from using Linq is readability. It allows the code to express what it is doing rather than how it is doing it. Compare:

    foreach (var item in list)
        if (SomeCondition(item)) return item;
    return null;
vs.

    list.FirstOrDefault(item);

Re: LINQ Ruined My Favorite Interview Question

#62

> “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?

> there anything else missing?

You named more than I detected.

Re: LINQ Ruined My Favorite Interview Question

#63
post #44
post #8

I 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…

While we're golfing, (comp first rest) is equivalent to the stdlib function called second , or, perhaps more idiomatic for map entries, val . We can also flatten deeply nested chains of computation using the -> and ->> macros, like so: (->> (string/split ... #"\s+") frequencies (sort-by val) reverse (take 10))

If the aim is golf, it's probably best to keep #" ". If the aim is accuracy, we might get better results by using #"[^\w]+". Though that does nasty things to words like "it's".

Edit: Actually, we can also get rid of the 'reverse' by replacing (sort-by val) with (sort-by (comp - val)). Not going to be shorter in terms of character count, though we win on line count.

Re: LINQ Ruined My Favorite Interview Question

#64
post #31
post #21

Earlier quoted context omitted.

Well, sure, once you're allowed to use external libraries anything is a one line solution. In JS: doStuff = require("doStuff"); var result = doStuff(theString); isn't JS so efficient ?!?

Without imports: d = {} for word in s1.split(' '): try: d[word] += 1 except KeyError: d[word] = 1 print [(x, d[x]) for x in sorted(d, key=d.get, reverse=True)][:10]

In case anybody was wondering for a second when JS got so awesome -- it didn't, this is a snippet of Python. D'oh. Sigh.

Re: LINQ Ruined My Favorite Interview Question

#65
post #8

I 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…

how does FREQUENCIES know how to compare strings? In Common Lisp you'd usually supply a TEST keyword parameter (#'STRING= or #'EQUAL in this case). Does Clojure use Java's type system to infer?

http://docs.oracle.com/javase/6/docs/api/java/lang/Object.ht...

Re: LINQ Ruined My Favorite Interview Question

#66
post #13

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.

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 s…

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.

Re: LINQ Ruined My Favorite Interview Question

#67
post #31
post #21

Earlier quoted context omitted.

Well, sure, once you're allowed to use external libraries anything is a one line solution. In JS: doStuff = require("doStuff"); var result = doStuff(theString); isn't JS so efficient ?!?

Without imports: d = {} for word in s1.split(' '): try: d[word] += 1 except KeyError: d[word] = 1 print [(x, d[x]) for x in sorted(d, key=d.get, reverse=True)][:10]

[deleted]

Re: LINQ Ruined My Favorite Interview Question

#68
post #31
post #21

Earlier quoted context omitted.

Well, sure, once you're allowed to use external libraries anything is a one line solution. In JS: doStuff = require("doStuff"); var result = doStuff(theString); isn't JS so efficient ?!?

Without imports: d = {} for word in s1.split(' '): try: d[word] += 1 except KeyError: d[word] = 1 print [(x, d[x]) for x in sorted(d, key=d.get, reverse=True)][:10]

I'm a newbie, but the question seemed approachable so I went for it. This is what I came up with. (Python, btw.)

  def top_ten(s): 
    words = s.split(' ') 
    word_list = set(words) 
    return sorted(word_list, key=lambda x: words.count(x))[:10]
The question didn't ask for word counts, so I didn't see the need for a dictionary. I'd appreciate any advice on my solution. I'd be thrilled if I'm not too far off from being capable of starting to apply for jobs.

Re: LINQ Ruined My Favorite Interview Question

#69

Earlier quoted context omitted.

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 s…

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.

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).

Re: LINQ Ruined My Favorite Interview Question

#70
post #13

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.

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 s…

(Note: When I say LINQ I am referring to the functional style it encourages, not the query syntax. The query syntax is nice, but it's just a trivial syntactic transformation.)

Correct me if I'm wrong, but the world is moving towards functional programming (i.e. LINQ) not away from it. Personally, I find LINQ far, far easier to read, write, and analyze. (On the other hand, I understand the deferred semantics and watch for warning signs like enumerating a sequence more than once.)

Honestly, a C# company avoiding LINQ sounds to me like the canary in the mineshaft telling you the company has programmers falling behind the times and doing things the hard way.

Post reply on HN