Prev: WPF Dispatcher queues - race condition
Next: explicit cast
From: Peter Duniho on 22 Feb 2010 15:15
Rich P wrote:
> Thanks for this code sample - works great. This is a little bit easier
> to follow - what is going on than the LinQ -- although the LinQ was
> several lines shorter. Dictionary is still great though, for when I
> can't figure out a LinQ method.

Right. The point being, a heavyweight solution shouldn't be your first
fallback. It's better to figure out the LINQ, but barring that, it's
important to consider that whatever LINQ can do, it does it without the
benefit of a major component like a database.

As far as what's "easier to follow", as I mentioned, I think it's
important to understand what LINQ is doing behind the scenes, just as I
think it's important for all high-level programming languages and tools
to still understand what the underlying implementation is really doing.

But one thing that LINQ really helps address is for the code to show
better what you _intend_ for it to do, than for _how_ you intend it to
work. Of course, in doing so, you lose much of the "how" aspect of the
code. But that's what higher-level programming techniques are all
about; to express more clearly _what_ you want the code to do, and leave
the _how_ to the programming platform.

So the LINQ version is not only more concise, it clearly expresses that
the "what" is "group the data". The explicit version I posted doesn't
really express that at all. It's left to the programmer to figure that
out, after examining the "how" closely.

IMHO, in this particular case, I find the LINQ much better. And in
general, as long as the LINQ is easy to write and simple to read, it's
better. I've seen LINQ abused, but as long as it's used only where it
really does express the "what" much better than a more explicit
implementation would, I think it's an improvement.

Pete
First  |  Prev  | 
Pages: 1 2 3 4
Prev: WPF Dispatcher queues - race condition
Next: explicit cast