Hacker News Reader

Comment by overgard | Hacker News Reader

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 (although it's a tradeoff, as the one downside of LINQ is that given it's deferred nature, it's harder to debug).

View on HN

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

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.

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.

You really only have to figure it out once. And for users not familiar with the "standard" names, I think linq's naming is actually more intuitive.

tbh I don't think either are particularly intuitive in a "can guess it" sense. Both are intuitive in a "oh, that's what it's called, I can remember that now" sense.

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.

Well, SQL is by far the most used functional language in the world.

I do Lazy LINQ, by which I mean I write the looping code with "foreach"es and get it debugged & working, but then allow Resharper to convert it to LINQ if it can.

I think this is mostly because I'm still not comfortable with the syntax, and partly because of the set/iterative impedance mismatch that is there. "It's not you, LINQ. It's me."

You would really benefit from learning a functional language (any) to help you roll your own LINQ. Some of Resharpers refactoring to LINQ is awful and does not make for cleaner code.

I almost feel a bit gross when I have to write a "foreach" loop at this point

Agreed. I've transitioned to spending most of my time in JS, and wherever I can I use .map(), but the chaining it's not quite the same as LINQ. Someday I intend to write a library of Array addons to provide GroupBy and so on, but I can't imagine it'll be super efficient.

Underscore has groupBy and some of the others you may be looking for.

Yes.. I do understand why extending the base Array object in JS is deeply frowned upon but at the same time I often wish that these sort of extensions were on the Array object. It feels clunky to use them otherwise.

You should check out Sugar, by far my favourite standard JS lib to use in any complex project: http://sugarjs.com/

This is the problem with doing functional list stuff in languages that permit side effects: the order of execution for each function has to be strictly defined (in both senses of the word), so the compiler can't optimise the code. In Haskell the solution (see my comment on the original page) would probably (I haven't actually checked the GHC core output) be folded into a single loop.

In Underscore, you can do something like:

    _([ ... ]).map( ... ).filter( ... ).value()

It's not exactly extending the native array...but there are far fewer side effects to doing it this way.

The problem with this is that it's doing multiple iterations. LINQ on the other hand builds up an expression tree that is "compiled" into a single loop when `ToList()` (or some other method which gets the results) is eventually called.

This may be what you're looking for. I think it was developed my MS specifically for this reason:

https://github.com/Reactive-Extensions/RxJS

Reply on news.ycombinator.com