Location of MVC Assemblies

MVC 5

C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Stack 5\Packages\ Microsoft.AspNet.Mvc.5.0.0\lib\net45\System.Web.Mvc.dll

MVC 4

C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4\Assemblies\System.Web.Mvc.dll

MVC 3

C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 3\Assemblies\System.Web.Mvc.dll

MVC 2

C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 2\Assemblies\System.Web.Mvc.dll

Lambda hate, Lambda expressions suck?

From a Microsoft employee in 2005:
C# 3.0: Lambda expressions. I don't like it that much....
http://blogs.msdn.com/b/abhinaba/archive/2005/09/17/469568.aspx



From 2008, regarding Jon Skeet's book's love for them, with reply by Skeet:
Lambda expressions: Dangerous Madness
http://bytes.com/topic/c-sharp/answers/829866-lambda-expressions-dangerous-madness



From 2010 on StackExchange, upvoted 33 times:
Does the usage of LINQ and Lambda Expressions lead to less readable code?
http://programmers.stackexchange.com/questions/24940/does-the-usage-of-linq-and-lambda-expressions-lead-to-less-readable-code


https://www.google.com/search?q=lambda+expressions+suck&oq=lambda+expressions+suck



http://www.google.com/trends/explore#q=Lambda%20Expressions

July 2007 is when it hit big, but seems to have hit India before the US, which doesn't spike until January 2008.



===================
The first one, from 2005, at one point says these gems:

Why I don't like lambda expression in C#

C# has originally developed from C++ /Java and is (was :^) ) a strongly typed object-oriented language. The new features being introduced like closure, continuation (yes, yes very limited continuation) in C#2.0 and now type inference, lambda expressions are de-generating the language. Even though there are people go gaga aboutcontinuation and lexical closures these are fundamentally functional language features and should be left to that. Introduction of bits and pieces of functional language features are not going to add value to C# and at the same time the surface area of C# is growing beyond what most developer can grasp.

Every language has a domain of application and an audience. Most people who work in C# developing web-services and web-based applications today are not necessary computer science grads. For them these concepts are a huge variation from the way C# used to behave. Functional programming is for the academia and not from the industry and should be left as such.

If I am asked, whether I'll use these language features, my answer will be maybe, and that is because the code written by me will be reviewed and maintained by people in MS who are fairly conversant with these. However, I think these features add burden to the learning curve of people who are not super interested in C# and should be avoided in favor of easier language constructs’ that might take couple of lines of code more, but would be more readable and maintainable.

These are just my opinions and I'm sure the designers of C# had given a lot of thought before adding them, but I strongly feel that these features are just adding more surface area to the language and will mostly go unused by the masses.

Some comments were like this:

" I think your comments about keeping C# "easy" so the web monkeys can understand it are off base. That's why we have VB.NET. 

Keep VB simple and leave C# to the real developers."

Joe Chung 

6 Mar 2007 10:07 PM 

#

I think it's funny how all these C# programmers like to look down on VB.NET programmers because they're Morts, but give them something that isn't absolutely trivial to understand, then all of the sudden they're becoming incredibly uncomfortable with the notion that they're just Morts that like curly braces.
Suck it up and learn how to use it.  It's going to become part of C#.  Or admit that you're just a Mort that likes curly braces.

Alexandre Grenier 

27 Nov 2007 1:10 PM 

#

Wow, this post is so old, yet still going!
My take is you can't just take one of the C# (1.0, 2.0, 3.0, etc) language feature and dice them up like this.
If you go beyond the vertical examination of the language as a computer scientist, and you apply those concepts horizontally as an architect or developer, you will see how the lattice is interwoven.
Pete, please don't give us the non academic and business semantics crap. Non academics are usually the ones writing the business efficient pragmatic code that makes it to production.
As for wasting business dollars on IT, blame the business men hiring the cheapest IT staff, not staffing an architect, and pushing through without a plan. The choice of language is hardly ever the cause of software project failures.
It's usually the business nerds coming up with arbitrary Gantt charts that screw things up before the first line of code is ever written. If you have a time and cost schedule before you have a team and a platform, your project is failed already.
Back to Lambda expression, they solve a very real need in both the business and development worlds, to express problems with the least possible syntactic pollution.
If the developer can't figure out the problem expressed in Lambda, then the only part they can figure out in an alternative syntax is that very syntax. The problem expressed will be obscured and even less understood by the developer. This goes back to the business nerds hiring idiots that code for cheaper.

• Chuck 

  6 Jul 2006 2:17 PM 

  #
  

  "My opinion is, lambda expressions will come as a shock to the community, yes. but they'll soon get over it and start to love it."
  
  I think you are overestimating 87.9% of .Net developers.  Don't forget, many of these guys are the same ones that started out with VBScript+ASP only 5-6 years ago with no background in mathematics, computer science, or engineering and no desire to "learn" a programming language.  And now you are expecting them to learn about relatively high level and abstract (again, relative) language constructs??
  
  Not going to happen.  As snazzy as the feature is, I think it'll go unused by the majority of existing .Net developers.
  

• Tom 

  23 Dec 2009 11:33 AM 

  #
  

  Good discussion. My complements go out to abhinaba, the author, for his willingness to criticize a major language feature and spark such an interesting interchange.
  My gut reaction is to side with him. Like many other folks have said, different languages have different 'essences.' The essence of C# I think was to make the Microsoft version of Java (which was stealing so many developers) and throw in some C++ syntax to make that crowd happy. If that is true, then I would argue that abhinaba is correct, as the driving purpose of Java was to create a language which was an elegant interpretation of OO that fit business needs. The addition of features that allow C# to be a one size fits all language detracts from this paradigm.
  In the words of the President of the Federation of planets circa Star Trek VI, (approximately) "let us redefine progress such that just because we can do such a thing does not mean that we must do such a thing."
  
• James 

  14 Jan 2010 10:46 AM 

  #
  

  Now here we are in 2010.  I transferred from a Java project to a .NET project last year, and I have to admit that lambda expressions have been one of the best things for us.  It's true that the people where I work are all smart folks, so I guess maybe lesser engineers might get confused, but I really don't think it's that confusing.  It took me all of maybe several seconds the first time I saw lambda notation to figure out what ".ToDictionary(x => x.Key)" does, and it only took a few seconds more to realize that it saves me about four lines of repetitive code to maintain.
  Of course nowadays it's clear that lambda expressions, besides being a good idea in and of themselves, were also a necessary building block in order to introduce LINQ.  In the months since our .NET project began, we have been able to leverage lambda expressions, LINQ, and expression trees generally to create an architecture that is far more flexible and easier to maintain than it would have otherwise had to be.
  Performance-wise, any hit we take due to the necessity of building expression trees and such is more than compensated for by our ability, using LINQ to Entities, to dynamically generate queries that produce all the data (and only the data) we want, in a single database round trip.
  Could the same functionality have been implemented in Java?  Yes, technically, but not practically.  Because we live in a practical world, time saved on writing and maintaining code takes something that was always "technically" possible and actually makes it available to you in real life.
  Maybe I just have the advantage of retrospection. I don't know what I would have felt if I'd been programming in C# for years and lambda functions were just getting introduced.  But looking back, I'm sure glad they were!
  And, by the way, I would argue that C# is still STRONGLY typed: It just doesn't always have to be EXPLICITLY typed.  The var keyword gives us the advantage of compile-time sanity checks without requiring us to be overly repetitive ("Dog dog = new Dog()") or unnecessarily verbose ("Expression<Func<Dog, bool>> dogCriterion = ...").
  
• Valko 

  11 Apr 2010 11:01 AM 

  #
  

  Now we are in 2010. I have 20 years programming experience and I do use lamda expression but in 90% of the cases those projects are nightmare to support. The problem is you simply cannot find qualified programmers that do understand code complexity. Anybody can develop complex code. The problem is when you need to maintain that code later. So from business point of view all this "improvements" are pointless. The fact we have this long thread is the proof. Making something anonymous and closure automated is not help at ALL from maintainability point of view. And from business point of view I've seen this types of programming:
  1. Simple code complexity with many lines of code - that is the most usual case, you still can maintain it.
  2. Complex code meaning (like lamda, can be understand by 10% of the folks on the field) with less lines of code - that is the worst case.
  3. Simple code meaning (can be undertsand by ANYBODY) with less lines of code - that is the best case scenario, I can write this one ;-)
  Good software programming is reducing the complexity on ALL levels. Introducing language features that increase complexity (language surface) is a pure nonsense and the sooner Microsoft realize it the better. The whole idea of having .NET framework is about making the basis of the future programming more simple by shielding the language from the implementation, which contradicts this idea with making the language overly complex.
  That is my 2 pence form the real life projects.
  cheers
  Valko

Another good read:

https://softwareengineering.stackexchange.com/questions/160368/why-is-the-use-of-abstractions-such-as-linq-so-taboo