6 ms·

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 compreh

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.

corresation 14y ago
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.
- recursive 14y ago
  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.
- NateDad 14y ago
  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.
  - jaegerpicker 14y ago
    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.
    - corresation 14y ago
      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)
- SideburnsOfDoom 14y ago
  > 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.
  - corresation 14y ago
    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.
    - SideburnsOfDoom 14y ago
      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.

corresation 14y ago

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.

recursive 14y ago
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.
NateDad 14y ago
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.
- jaegerpicker 14y ago
  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.
  - corresation 14y ago
    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)
SideburnsOfDoom 14y ago
> 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.
- corresation 14y ago
  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.
  - SideburnsOfDoom 14y ago
    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.