Hacker News Reader

Comment by corresation | Hacker News Reader

While a bit of an aside, personally I find LINQ to have been a horrendous misstep in the evolution of the language. While the argument that it makes code more concise and easy to maintain holds in the small, once a project grows it becomes a terrible cancer -- everything becomes an amorphous blob of stuff, unintuitive, performance-disaster LINQ filters applied everywhere to bend it into shape.

View on HN

Yes, but it's not specific to LINQ or MS or C#. If you give a tool to mediocre developers to make things easier they will use it right away. If you don't supervise its usage (how it fits into the architectural goals of the project you are on) you will end up with a mess.

Anonymous methods, unnamed classes, try catch blocks are all examples of these type of tools that when used improperly will kill the system performance, code readability, maintainability and extensibility.

Yes, but it's not specific to LINQ or MS or C#

We are specifically talking about C#. LINQ was specifically held as one of the improvements to the language. I am not quite sure what your point is relative to that.

There are shockingly few examples where LINQ is superior to alternatives. LINQ is the brute force technique of avoiding proper collections/algorithms.

I don't understand. Are you saying that map, filter, reduce and al. on lazy sequences in functional languages are inferior to loops, or that Python list comprehensions and generators are inferior to loops? That's basically LINQ to objects.

Maybe you're refering to LINQ-to-whatever (LINQ to SQL, etc.), a LINQ generalization where you can quote your expressions, rewrite the AST and emit something else (a very constrained kind of macros, if you will).

MS is probably to blame here, but people keep conflating the two.

In the vast majority of cases it is nothing more than syntactical sugar around loops. And no, I'm not saying that loops are superior, but rather I'm saying that loops are usually a terrible solution, but LINQ has a way of essentially hiding those egregious violators.

Take a block of code with LINQ in it and rewrite it minus LINQ but logically performing the same operations that the sugar is resolving to. To most developers it would offend the sensibilities of construction, but somehow in LINQ-land all seems fine.

95% of the time, what looks like a failed "loops 101" test actually doesn't matter at all. Maybe your list comparison function takes O(n^2) time... if your list never gets above 10-20 objects, who cares? Yes, if you're running LINQ over a list of 1,000,000 items, then you'll want to be careful what you're calling. But how often does that really happen in mobile apps?

What LINQ does is make your code more concise and readable. It makes it easier to find bugs and easier to understand by someone else (even if someone else is you, 6 months down the road).

It also just takes a lot less time to write.

Depends on what kind of mobile apps you are writing. Most of the apps I've worked on written tend to deal with video/ pixel level image conversions. In these cases it's really common to say convert an rgb pixel array to yuv or simliar and a linq expression on one of those arrays would quite simply kill the app. Which I think is the best counter argument to the op. C# might be fine until you decide to do something beyond the normal performance wise. Then you are back to square one learning the native supported tools, IMO you are much better off learning the native environments from the ground up.

This is really the crux of it. The counterargument essentially seems to be that such broad abstractions are fine in the small or when you have enough hardware, however that in no way carries over to smartphones where you want to do the most with the least, and even where you have a kick-ass processor and multi-GB RAM, you still want to reserve battery. The primary reason Android seems to need so much more hardware than iOS can be attributed to this. Even when you have powerful hardware, this can kill you in the large (which was the original failure of Windows Vista -- people forget that Microsoft did a complete revert after thousands of man years of work)

Most developers I know seem to prefer the loop version. I'm not sure what you mean by "sensibilities of construction", but I'm a big advocate of LINQ. If your concern is that certain linq calls iterate an entire sequence, that could apply to all kinds of scenarios that have nothing to do with LINQ like string concatenation. You should always be aware of the performance characteristics of methods you are calling. LINQ is not special in that regard.

> I'm saying that loops are usually a terrible solution, but LINQ has a way of essentially hiding those egregious violators

So when you want to sort, search or transform a list, you prefer a technique which doesn't iterate over the items in the list at all? That makes no sense.

I prefer a technique where algorithms and computer science come into play. e.g. dictionaries, hashes, binary trees, structured data based upon the actual uses, etc. Having a giant array of memory objects and then treating every bit of code like it's some edge condition is not appropriate.

I agree that Dictionaries and the like are under-used.

But I don't agree that LINQ is bad because someone on your team didn't know how to use a Dictionary and thought that iteration would be fast on large in-memory lists.

In many cases there are efficient LINQ constructs, e.g lazy lists, and First() not enumerating past the matching item. Hand-coding these is prone to doing it worse than Linq would. Teach your team how to use .ToDictionary() if need be.

The point is relevant in relation to the fact that you held LINQ out as a misstep, but the reasons you cite can be applied to many features of many different languages.

Yes, but rather than actually arguing with his point, you are showing how it could also be used to criticize some other language features not in an attempt to prove him wrong, but rather to pander to anybody reading the argument who likes those language features.

Could you give an example of that?

Personally, I like LINQ a lot. I don't use it very much in my code (and usually it's for things like light filter or ordering), but it has these little things that save a lot of time.

Be careful what you ask for -- you have to admit that it is possible to create some horrendous "code" with Linq. Also I have a hunch that OP is thinking of L2S or Linq2Entities or somesuch.

Well, horrendous code can be created with anything: LINQ, C#, Objective-C... But yes, such easy-to-use tools like LINQ are easily overused and you end up with real monstrous code.

This times a million. The amount of shit I have to deal with where people have used it in criminal ways is unreal.

Fine examples:

.ToList() materialization multiple times in a call graph. Ok so the thread is eating 200mb of ram?!?!?!

Generic method hell.

complete lack of understanding regarding IEnumerable, ICollection, IList etc.

O(log N) that doesn't go bang until you stick a production dataset in it.

The specification pattern - bottled rape is the only way I can quantify this. Sounds great until you have 2500 specifications and are stacking them 20 deep and your ORM decides it has had enough of clauses (EF4 bug).

My favourite: junior developer turns up and says "I wrote this awesome linq query - come and look!". Get there: all of the above.

These are great concrete examples that are very Linq specific. I cringed reading a few of them. The .ToList() materialization can easily be avoided by using a little skill, but the realities of late binding that don't show up until you hit production -- this can catch anybody.

We need to separate LINQ, the C# language feature, from the library implementation, LINQ to SQL or Entity Framework. The later does tend to cause issue because it offers a rather leaky abstraction over your database and poor performance. But it doesn't have to be this way. Case in point BLToolkit, a lesser known database access library that uses LINQ. It is light and almost as fast as native access. Very close to Dapper in performance or pretty much the same in performance if you compile your expression trees, but of course you have type-safety. Of course it doesn't have all the bells and whistles of L2S or EF, but you gain speed and simplicity.

> I find LINQ to have been a horrendous misstep ... grows it becomes a terrible cancer -- everything becomes an amorphous blob of stuff, unintuitive, performance-disaster LINQ filters

I couldn't agree less. Any language construct can be abused, but LINQ is not particularly susceptible to abuse, unless you try very hard.

LINQ is from the outset designed for abuse, and you don't have to try hard whatsoever.

That hasn't been my experience, I'm glad to say. And given the amount of c# code I've worked on already, it's unlikely to ever be.

Can you expand on what exactly you mean by LINQ? Do you mean the .NET library support (extension methods on IEnumerable/IQueryable)? Do you mean the language features added to C# (anonymous types, expression trees, nicer lambdas, query syntax)? The language features, with the possible exception of query syntax, seem like hugely beneficial additions, to me.

This is a fundamental place where the worlds of C# and Java differ. Where the Java world would say, "developers might misuse this, better not have it in the language," the C# world says, "developers could really use this, better put it in the language."

And if you've worked on a large project with a lot of cats to herd for both platforms, you will appreciate java very quickly.

But it doesn't appear (anecdotally I admit) that people feel that way. Seems the "whole world" (speaking loosely) is turning against Java because of this very philosophy.

Because Java has been so conservative, people actively hate it's verbosity, boilerplate-ness, and lack of language features (anonymous functions, first class functions, etc.).

So Java has, for many years, helped huge teams of mediocre developers avoid certain kinds of self-inflicted wounds by being conservative in terms of language features. And the result seems to be that Java is increasingly scorned.

I know if I had to replace my C# work with Java, I'd feel incredibly frustrated at the lack of language power. In fact, I wouldn't choose to do it -- it would have to be a hell of a project or opportunity to pull me into it.

(Luckily for me, there are many better options, like Clojure or Scala on the JVM, or Haskell, Python, Ruby, etc. off the JVM).

I'm not sure java is being increasingly scorned. The scorners are just noisier.

I work on a pretty huge C# code base. Use of LINQ is the least of it's problems. If anything I'd say one problem is people not knowing about things like lambda expressions, linq, generics or whatever. It can really make code harder to parse when it's written in ways that don't take advantage of the full power of the platform.

Yes until we get to:

List<List<Tuple<int, Dictionary<string, object>, string>>>

If you're doing that it's crap code; you should have defined a few named object types. Maybe your "Dictionary<string, object>" is e.g. actually a "PropertyMap". this is not a problem in the c# language.

Not at all - you just missed a few facts that need considering. Lets rip it to bits some more:

It's in system.windows.forms isn't it? Don't really want that dependency and associated resolution being dragged in to a web app otherwise the compiler has to load the entire assembly's metadata.

Also, it requires full trust.

Oh and finally it isn't serializable.

Which is why we end up with SerializableDictionary<K, V> which is even longer and is an adaptor for Dictionary<K,V> which implements serialization.

That's why it all sucks.

And I haven't even included ConcurrentDictionary thread safety yet.

The whole thing is a fucking mess.

The typical experience isn't that bad, let alone "The whole thing is"

In my experience, that kind of stuff is usually a problem mainly because of C#'s verbosity from lack of type inference. Although, with 4 unnamed elements there, it might start making sense to create a new type, and then it's just "List<List<MyRecord>>".

How much of that C# code pre-dates the availablilty of those features?

Some of the code was certainly written before those features was available, especially some C# 4 features. I'm sure someone might look at my code someday and wonder why I didn't use async and await. I'm talking about code written today though.

I concede the point. I hope I never have to herd that many cats.

You don't even have to use LINQ at all with C#, it's an extension library and not one that needs to be referenced or is even included as a default namespace. LINQ is very convenient to use on in memory objects where there's no noticable performance hits. Even LINQ->SQL produces somewhat optimized SQL. How else would you bend data into shape without an ORM layer? Writing custom stored procedures, adding a whole bunch of new service methods, or manipulating data tables directly?

This 'cancer' is simply a data layer; if you use proper design patterns and seperate your layers correctly, you can surgically remove this tumour and replace it with another ORM.

LINQ is indeed optional, but this discussion is about the evolution of the language, with LINQ being held as an improvement. And because it is new and shiny, C# code across the globe quickly became infected with it.

Your comment on "where there is no noticeable performance hits" strikes a chord because when first used there are no noticeable performance hits. But then that application grows and scales and suddenly it is death by a million paper cuts, thousands of grossly inefficient set operations devastating performance. That's aside from the fact that LINQ is often a short-circuit saving from having to think about appropriate algorithms of object-methods to deal with the likely uses.

LINQ is just another tool in the toolbox. Like any tool it has the potential for misuse. Ultimately the skill of the person wielding the tool will decide whether the outcome is good or bad. It sounds like you've mostly seen the bad. In the right hands, LINQ can make things more readable and concise.

Take another example, anonymous functions in Javascript. I've seen plenty of tremendously horrible JS code bases that were just a deep series of nested anonymous functions. Almost impossible to debug or maintain. However, when used appropriately the anonymous function is very powerful and can make certain things much easier.

Reply on news.ycombinator.com