Live data from Hacker News

LINQ Ruined My Favorite Interview Question

scottchamberlin.tumblr.com

31–40 of 218 posts

Re: LINQ Ruined My Favorite Interview Question

#31
post #21
post #19

Earlier quoted context omitted.

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)

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]

Re: LINQ Ruined My Favorite Interview Question

#33
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 ?!?

collections isn't an external library. It's part of the Python standard library.

[deleted]

Re: LINQ Ruined My Favorite Interview Question

#34
post #12

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

I agree with your pain points.

We try to use ICollection in our APIs instead of IEnumerable, since the latter can have surprising semantics like being a wrapper for some operation which may not be valid anymore, or might be slower than you expect to do things like .Count(). IMO it's really not best for transporting across interface boundries in the most common case; only when you're specifically trying to avoid having the whole collection in memory or something like that.

Another thing that can help is this wonderful May library[1]. It a great option type[2] for .NET. It helps make operations more composable.

[1] https://github.com/Strilanc/May

[2] http://en.wikipedia.org/wiki/Option_type

Re: LINQ Ruined My Favorite Interview Question

#35
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…

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.

Re: LINQ Ruined My Favorite Interview Question

#37

Why are you allowed to ask technical question whens you dont even understand how LINQ works under the hood. This material is nearly 6 years old and even a dated Jon Skeet book would suffice. WTF.

Any dot net dev not familiar with littered .toList need to pack their bags.

Re: LINQ Ruined My Favorite Interview Question

#39
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.

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.
Post reply on HN