foreach (var item in list)
if (SomeCondition(item)) return item;
return null;
vs. list.FirstOrDefault(item);61–70 of 218 posts
foreach (var item in list)
if (SomeCondition(item)) return item;
return null;
vs. list.FirstOrDefault(item);> “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?
You named more than I detected.
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))
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.
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 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?
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…
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]
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]
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.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.
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).
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…
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.