Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LINQ Ruined My Favorite Interview Question

scottchamberlin.tumblr.com

Post reply on HN
Print view View original

161–170 of 218 posts

Re: LINQ Ruined My Favorite Interview Question

#161

Post by gboudrias »

What is it with people's obsession over lines of code?

As someone who doesn't do C# or LINQ, that second solution seems to me like someone really wanted to have as few lines of code as possible.

I don't claim to have an impressive programming pedigree, but while I take simplicity and performance into account, I never take "conciseness" into account. Conciseness usually means "this is opaque as shit but at least it's short". And who really cares about short? What's the purpose of "short"? None that I can find, other than impressing interviewers. Anyone who believes otherwise should probably be writing in Clojure or Haskell (and probably is), but I personally just don't see the point.

But that's just my opinion. My favorite language is Python.

Re: LINQ Ruined My Favorite Interview Question

#162

Post by dyselon »

PommeDeTerre wrote: post #153
MatthewPhillips wrote: post #35

Earlier quoted context omitted.

The most annoying thing about LINQ is that they use the SQL language. So unless you use C# and LINQ all of the time it's hard to figure out what functions translate to the ones used by every functional language in the world. I wish they would at least alias map, reduce, some, etc.

Many C# users have experience with SQL, but not necessarily with functional programming languages. The number of these users likely far outnumbers the number of C# programmers who know functional programming languages, but not SQL. It makes sense to use terms that many C# (and SQL) users are already familiar with, rather than terms that they may not know of.

I understand the rationale, but in my experience knowing some SQL didn't help me understand LINQ at all. It was only after picking up some functional experience elsewhere and coming back to C# much later that LINQ made sense to me. I'd be really curious to see how the SQLesque naming's worked for others, but it was a bit of a miss for me personally.

Re: LINQ Ruined My Favorite Interview Question

#163

Post by jules »

jessedhillon wrote: post #72
spenuke wrote: post #68

Earlier quoted context omitted.

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…

This is a great approach. Even better because you carefully examined the requirements and found an interpretation which allowed you to make an optimization (words only, not counts, therefore sets are useful)

This isn't an optimization. He turned a O(n) algorithm into a O(n^2) one.

Re: LINQ Ruined My Favorite Interview Question

#165

Post by tel »

Here's the Haskell golf

    import qualified Data.Map as M
    import Data.List
    import Data.Ord

    countWords :: String -> [String]
    countWords = map fst . take 10
               . sortBy (comparing snd)
               . M.toList . M.fromListWith (+) . map (\w -> (w, 1)) 
               . words

Re: LINQ Ruined My Favorite Interview Question

#166

Post by tel »

aphyr wrote: post #120
moomin wrote: post #117

Earlier quoted context omitted.

Think you also need a (map key) there to be equivalent to the C# code. At which point it's starting to look very similar to well written C# code solving the same problem. Much as I love Clojure, it's worth pointing out that Clojure's lazy sequences (include intermediate sequences) get cached, while LINQ evaluates more like Clojure's reducers. (You can even get it to do so in parallel.)

You're right; it does need a (map key) line to be equivalent. I was thinking of http://www.leancrew.com/all-this/2011/12/more-shell-less-egg... , which wants the counts too. :) On a side note, I'd like to point out a key difference between this Clojure example and corresponding variants in C#, Python, &c: the Clojure variant has no variables . This isn't just a matter of concision: coming up with descriptive names is…

Pointless style gets a bad rap, but the idea that you're thinking of just the transformations instead of the data is a powerful mindset to have.

Re: LINQ Ruined My Favorite Interview Question

#167

Post by yen223 »

wiredfool wrote: post #126
CanSpice wrote: post #115

Earlier quoted context omitted.

"Sorry, we're stuck with Python 2.3.7 and collections isn't part of the standard library."

"""Thank you, I think I've heard enough. I don't think continuing the interview would be a productive use of time."""

I like the fact that you triple-quoted that statement.

Re: LINQ Ruined My Favorite Interview Question

#168

Post by Pxtl »

aphyr wrote: post #120
moomin wrote: post #117

Earlier quoted context omitted.

Think you also need a (map key) there to be equivalent to the C# code. At which point it's starting to look very similar to well written C# code solving the same problem. Much as I love Clojure, it's worth pointing out that Clojure's lazy sequences (include intermediate sequences) get cached, while LINQ evaluates more like Clojure's reducers. (You can even get it to do so in parallel.)

You're right; it does need a (map key) line to be equivalent. I was thinking of http://www.leancrew.com/all-this/2011/12/more-shell-less-egg... , which wants the counts too. :) On a side note, I'd like to point out a key difference between this Clojure example and corresponding variants in C#, Python, &c: the Clojure variant has no variables . This isn't just a matter of concision: coming up with descriptive names is…

Yeah, I tend to prefer the lambda notation over the sqlish notation, but either way the lambda form of your solution would be similarly terse. The select call that constructed an anonymous-typed object was unnecessary, as were all the temporary variables... C# coders should never be afraid to embrace the Rubyish leading dot approach.

  return s.Split(' ')
    .GroupBy(word => word)
    .OrderByDescending(wordGroup => wordGroup.Count())
    .Select(wordGroup => wordGroup.Key)
    .Take(10).ToList();

Re: LINQ Ruined My Favorite Interview Question

#169

Post by softbuilder »

runT1ME wrote: post #132
overgard wrote: post #4

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

>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") Actually........ It's more generic than that. It's C#'s monadic comprehension syntax ala Scala's for and Haskell's Do. It works on more than just IEnumerable, it actually works on anything that implements Select, SelectMany, and…

This is super obvious if you watch some of Erik Meijer's excellent videos on Channel 9. Recommended viewing for anyone reading this who hasn't. Watching him bounce between Haskell and C# felt like someone explaining etymology by moving between Latin and English.
Post reply on HN