It seems to me they are actually taking their head out the sand and realising the web is not all about Microsoft now and there is a whole world of new technology happening around them that they need to include in their products.
I think this is a prelim release to 5 as they want to show their commitment to becoming more engaging to html5 standards and other technology.
Also, there is a comment that this is a weak release for 2.5 years work, .net 4 had a massive amount of work done on it and this is a partial release. The library is already very concise so I would be interested to know what "massive" changes they could make right now apart from just making the library more stable.
Consider this the Windows version (in development terms) of the Leopard to Snow Leopard that Apple released.
Also I don't know who in their right mind would chose to use classic ASP.Net anymore.
But compared to 3.5 there's nothing in here that I find exciting or that's looking particularly like it's going to make my life as a programmer better. Personally I find the more they work on MVC the more they seem to be giving in to the temptation to put 'magic' in there like the old forms, which sucks imo as it encourages new programmers to write very bad code.
The main reason I started moving away from silverlight and more into html and js, mvc etc was because of Windows 8 not having silverlight as part of the interface.
This is exactly what I mean by Microsoft getting it's head out the sand though, they have chosen to use the more adopted methods going forward than it's own solutions. It's a sign that Microsoft are no longer at the center of the universe.
I'm not putting down your comment on who in their right mind uses "classic" asp.net any more but I find it a little closed minded as asp.net webforms is far more tried and tested. It's a developers choice and it's not a wrong choice to use forms over mvc.
Let me begin by praising the CLR and C#. Their latest features are great (both at runtime level and syntax level). But I have not seen something great (or notable) coming out from the .NET communities whether a new library, a new ORM, a new framework, a new paradigm, or even a new tool despite all these cool lambdas, task, linq, etc.
Why is that?
Coming from Java, a language/platform that is considered less superior, where there are tons of good tools like Ant, Ivy, Maven (is NuGet comparable to Maven? or still lagging?), or libraries such as JBoss Netty, JAX-RS, Spring MVC 3.0 (very close to Rails: routes, return XML/JSON depending on request, minus the ORM), JAX-WS (with annotation style programming), EJB 3.1 style programming (which helps a lot!), a few of NoSQL flavours to keep developers busy (Neo4J, Cassandra, HBase), distributed libraries such as Hadoop, I find this situation to be odd.
1. MS advances their product at a semi-decent rate so people just wait for MS to bring out a solution. I don't mean this as a dig, it just seems MS is more plugged into emerging trends in programming. Asp.net MVC came out within a year of Rails and Django becoming popular and lots of MVC frameworks appearing for PHP. I also had just seriously started playing with NHibernate when Linq2Sql and the Entity framework came out. Same with lambdas and all that goodness. They seem to bring stuff out just as people are saying 'hey, this is a really good idea'. I don't see that happening in Java. They get it wrong sometimes, like their over engineered SOAP solution which personally I think contributed to its downfall. Also WCF and WF are both pretty shitty.
2. I think a lot of the other tools is because Java came out first so some of these problems were were already solved when it came to .Net, so we got nant, etc. I personally have never worked on a project where something like Maven seemed worth it comapred to some slight customisations to MSBuild which you can do in VS, so can't comment on that.
With that said, there are some nice frameworks that exist, but competing against the top framework vendor, Microsoft, is tough. And while most on HN won't understand this, most .NET devs are actually quite happy with what MS is doing -- and most generally feel like MS actually does listen to the dev community.
I think you're onto something with your statement that Maven might not worth in .NET since there aren't many 3rd party libraries that you would include to your project. That is probably tied to point #1: relying on Microsoft to provide everything.
It's open source as well. Well worth a look.
For the most part, the .NET devs I know just don't care to be involved in community open source projects and/or use those projects as much as you see with other stacks. I do see that changing quickly though.
However, it is nice to see this new respect for MS I'm seeing from non-MS developers lately. Just a few years ago it was pretty depressing, but that seems to be changing.
1) Perhaps you don't use .NET a lot so maybe you're not as aware of all the great tools that are available (open or commercial).
2) .NET developers are more likely to be commercially minded. In other words, their tools aren't always free.
3) There really are a lot of great tools. Check out RedGate, JetBrains, Telerik or DevExpress .NET tools among others. CodeSmith. CruiseControl.NET. See also http://visualstudiogallery.msdn.microsoft.com/ .
Overall though, 4.5 seems like a pretty weak release for 2+ years of work. I hope that 5.0 was being worked on in parallel.
The core of LINQ essentially the same as the core of F# computation expressions and monadic do-notation in Haskell: two operators Return(x) and Bind(m,f). The name of Return is datatype dependent in LINQ, but its purpose is to create a container with a single thing inside. E.g. for IEnumerable Return(x) creates an IEnumerable with a single item x in it. Bind is called SelectMany in LINQ.
F# has something similar to async/await in the form of asynchronous workflows. It is implemented on top of computation expressions, i.e. monads. The F# async feature is similar to the continuation monad. But the F# designers didn't limit the computation expression syntax specialized to asynchronous computations, it actually works for any monad. For example for sequences (=~ IEnumerable in C#) and parsers and probability distributions. You can also do these same things with LINQ: you can do asynchronous computations and parsers, probability distributions, reactive streams (Rx) and many other things with LINQ.
The trouble is that the C# designers have limited the async/await syntax to just asynchronous computations. That means that you cannot use the very convenient async/await syntax for anything other than the async "monad". Had they not limited this feature and had they built the feature as a new syntax on top of the LINQ operators then you could use it for IEnumerable and parser combinators and anything else that implements LINQ's SelectMany method. Specifically async/await is limited to monads where Bind(m,f) invokes the continuation f exactly 0 or 1 times.
For the people who are familiar with the theory around monads, C#'s async/await basically correspond to Moggi's monadic reflection and reification operators. The async operator reifies a monadic computation (in this case limited to asynchronous computations) into a data structure, and await is the inverse that reflects a computation represented as a data structure into the computation.
The operator async takes a block of code representing an asynchronous computation returning a value of type T and turns it into a Task<T>, and await takes a Task<T> and runs it as an asynchronous computation returning a value of type T.
The operator reify takes a block of code representing a M-monadic computation returning a value of type T and turns it into a M<T>, and reflect takes a M<T> and runs it as an M-monadic computation returning a value of type T.
Considering the C# designers include Erik Meijer and work closely with Don Syme, I find it hard to believe that they didn't notice this. But you're right, it's not as powerful or general as what is in F# (which I really need to learn better, as every time I look at it, I want to code in it).
I suspect the C# designers looked at what one of the biggest problems they have is, and it is asynchronous computation (especially w/ respect to the UI thread) and said that F# async workflows solve this problem. But too generally. What do I mean by that. With the current C# solution the syntatic changes are minimal to a completely sequential program. It's not as general, but easier to write and understand.
I wouldn't be surprised if C# added async workflows full on in a future version, when they'll point to async/await and say "you've been doing it for years -- it's not hard at all!"
... Foo(await m) ...
let! x = m
... foo x ...
If that's the case then it would be great to hear the reason from one of you who are on the C# design team and reading news.yc :)
I'd second that. Maybe someone @MS could send this to the Async team?
I did kind of passively think that more syntax was not the way to solve these problems but shrugged it off. I've been slightly worried about the complexity of C# after some awful decisions (nullable types for examples).