Took a look at all the fuss about "lambda expressions" from JonYou are, of course, entitled to your opinion, but lambdas are a part
Skeet's excellent book "C# in Depth". *Jon has an example, reproduced
below (excerpt) on lambda expressions.
My n00b take: *it's like SQL and those 'high level' languages that try
to be too clever by half and pack a lot of syntax in as short a space
as possible. *Like Egyptian hieroglyphics, like Chinese, like those
non-alphabet languages, it's just way too much information in too
short a space. *Sure, writing a program with this syntax will reduce
your source code from 100 pages to 10, but at a cost of readability.
But what do I know? *I only have a couple months real experience in
the language. *Don't listen to me.
RL
"To try and outstrip each other in the arms race, or to expect to win
a nuclear war, is dangerous madness." - Leonid Brezhnev
this is equivalent: *from C#1.0
ArrayList products = Product.GetSampleProducts(); //fills arraylist
(fanciful example)
foreach (Product X in products) {
* * *if (X.price 10m) { Console.WriteLine(X);} } [suffix m =
decimal]
now redo in C#2 mode:
ArrayList products = Product.GetSampleProducts(); //fills arraylist
Predicate <Productproducts test = delegate (Product p) {return
p.Price 10m;} ;
List<Productmatches = products.FindAll(test);
Action<Productprint = delegate(Product p) {Console.WriteLine(p);};
matches.ForEach (print);
which is actually equivalent to (lambda expressions):
ArrayList products = Product.GetSampleProducts(); //fills, as before
foreach (Product product in products.Where (p =>p.Price 10))
{Console.WriteLine(product);}
*//Jon humorously states "the combination of the lambda expression
putting the test in just the right place and a well-named method means
we can almost read the code out loud and understand it without even
thinking" HA HA HA! *Right. *I guess beauty is in the eye of the
beholder.
of C# 3.0, and any C# developer has to know their ins and outs if only
to be able to maintain other people's code.
Also, every time I hear such sentiments - "generics/closures/type
inference/... are hard to understand and compromise
readability" (there were plenty of such as new major language features
were introduced, and not just in the C# land - come read some stuff
people write about Java generics, or the Java closures controversy), I
can't help but think that similar arguments took place back in 60s
during the transition to structured programming ("bah, those
newfangled loops are for lazy people who can't even be bothered to
type proper IF/GOTO - and of course, they result in utterly unreadable
code; look, the condition is checked without any IF present!"), and
then later from procedural to OOP (still plenty of flame on the Net
regarding this topic).
Luckily, there's no stopping the progress. You can invest some effort
to keep up, and join the ride, or you can retire to the same role as
people maintaining legacy COBOL systems today.
