Microsoft has always been top-notch when it comes to developer tools.

If it succeeds, it will reinvent how we view compilers and compiled languages altogether.

It's actually very similar to the Mono project's Mono.CSharp library, which exposes the Mono C# compiler as a service and enables a REPL console much like the one Hejlsberg demoed at Build.

Apparently "always" doesn't go that far back. I can remember a time when MS compilers and developer tools wasn't really used by anyone doing serious development. The companies making great compilers and dev tools was Borland and Watcom and many others. Ms, not so much.

Apparently "always" doesn't go that far back. I can remember a time when MS compilers and developer tools wasn't really used by anyone doing serious development. The companies making great compilers and dev tools was Borland and Watcom and many others. Ms, not so much.

So it's actually not all that revolutionary then. Not saying it's not good technology, I'm sure it is, but less hype wouldn't hurt, especially for a product with absolutely no shipment date whatsoever.

Reinventing? More like catching up.
Considering that Java is very slow at adopting new features, it already has had compiler API since 2006. (Excluding JDT and other tools.)

So what's the deal... is MS leaving .NET behind, or are they not? I thought WinRT was supposed to be the new 'Jesus API' to rule them all?

"So what's the deal... is MS leaving .NET behind, or are they not? I thought WinRT was supposed to be the new 'Jesus API' to rule them all?

RTFA. This isn't about exposing Compiler.AddFiles|.Run. It's about exposing each of the internal stages of the compiler so that you can essentially plug in your own lexical analyzer (for examnple) or your own code analysis tool (for example) fed by a tokenizer. This is fairly damned cool.

It's actually very similar to the Mono project's Mono.CSharp library, which exposes the Mono C# compiler as a service and enables a REPL console much like the one Hejlsberg demoed at Build.

Its very interesting, and I don't think anything quite like it has been done before, especially at runtime.

So what's the deal... is MS leaving .NET behind, or are they not? I thought WinRT was supposed to be the new 'Jesus API' to rule them all?

They complement each other. WinRT is replacing Win32 not .Net.

Things like adding custom extensions to the C# language (which are transformed at the syntax level, very cool).

Apparently "always" doesn't go that far back. I can remember a time when MS compilers and developer tools wasn't really used by anyone doing serious development. The companies making great compilers and dev tools was Borland and Watcom and many others. Ms, not so much.

Roslyn is so much more. You can hook into _every_ step of the compiler.

...
So I could write a WinRT component in C#, have the metadata autogenerated, and use it in C++ as if it was a native C++ class. Or use it in Javascript as a native javascript object.

...

How is exposing the internal API publicly a major departure and reinvention of compilers?

I'm not saying it's not great that they are exposing API that will stay stable. I just don't get the hype over this.
Please do hype up anything that grows up from this to be ridiculously fun or novel. But as it stands, Roslyn is not revolutionary or anything like that.

Compilers are tansformed from this classic vision of take a source file in -> generate code.
...snip...

I view this in the same light I view other exciting framework developments. When LINQ launched people were asking how this would be revolutionary, the same with Rx. Some concepts just take time to grasp.

I'm not sure we have the whole story yet. I'd be very surprised if they didnt open the WinRT up to desktop apps.

I mean, you can already do it, they just have not publicly said its a supported scenario. Plenty of examples online.

I wonder though how quickly the Windows 8 app store will fill up, and if it could possibly obsolete desktop apps to anything but legacy support.

But again, none of that is something new. Is it new to .NET?

LINQ: And yet, here I am 4 years later developing in every conceivable language outside of MS universe without LINQ making a dent.

Compilers are tansformed from this classic vision of take a source file in -> generate code.

Now, every aspect of the compiler is a service. I can do metaprogramming by transforming syntax if thats what I need. I can gather data from a previously or newly compiled program (or myself) using semantics.

I can transform code at the semantic level for an even more targeted approach to metaprogramming.

I can query the Solution/Project API and perform the same syntax/semantic analysis on those documents, or whatever else I want, then save the project.

I suppose that's your opinion, I just strongly disagree.

I view this in the same light I view other exciting framework developments. When LINQ launched people were asking how this would be revolutionary, the same with Rx. Some concepts just take time to grasp.

You have to reach back to the early 90s

And that's quite frankly forever in technology terms.

LINQ: And yet, here I am 4 years later developing in every conceivable language outside of MS universe without LINQ making a dent.

I don't understand with the obsession people have with undermining whats been done here. You guys try so hard to find something, anything, to knock this project on, because it can't possibly be that Microsoft innovates on anything.

Other platforms offer one aspect, or a few aspects of Roslyn. None of them does them all in as a cohesive language as this. Especially not for a statically typed language.

LLVM does no such thing on its own. Now if you take the LLVM backend, add in the Clang front end, then maybe you get something comparable to Roslyn.

Compilers are tansformed from this classic vision of take a source file in -> generate code.

Now, every aspect of the compiler is a service. I can do metaprogramming by transforming syntax if thats what I need. I can gather data from a previously or newly compiled program (or myself) using semantics.

I can transform code at the semantic level for an even more targeted approach to metaprogramming.

I can query the Solution/Project API and perform the same syntax/semantic analysis on those documents, or whatever else I want, then save the project.

Isn't this admittance that the CLR as system platform concept (expressed heavily during the Windows .NET era) has ultimately failed?
WinRT looks to be what CLR was supposed to be, pushed lower level to support serious C++ right (read COM 2). CLR on the other hand is left as a high level application dev wrapper/runtime for ever. Looks like dreams of managed only OS'es will remain pipe forever.

Roslyn is so much more. You can hook into _every_ step of the compiler.

Other platforms offer one aspect, or a few aspects of Roslyn. None of them does them all in as a cohesive language as this. Especially not for a statically typed language.

But from what I observe it is for metro-only applications - 30 years on and Microsoft still haven't come up with the horrific mess that is common controls and dialogues.

MS dev tools was bad well into the mid 90's. In fact, they only started getting good when Hejlsberg was hired in '96.

That's beside the point. MS dev tools wasn't "always" good. Period.

I did. I meant JavaC Compiler Tree API, not Compiler API.

BS. I used VS, Watcom, *and* Borland tools, going back to the 80s. VS was already pretty well-integrated in the early 90s.

October is sad month. Steve Jobs, Dennis Ritchie, and now John McCarthy.

Who can blame them, when you demonize the people who do? The Linux community in general treat the Mono guys like shit.

Well, I hope someone writes a tool to project WinRT APIs into the C programming language in a nicer way..otherwise you're stuck with an updated version of COM.

Under the hood, WinRT is all held together by COM. Only, slightly modernized.

The BASIC interpreter of the Commodore 64 & Commodore 128 were licensed from Microsoft if I'm not mistaken. I think that counts as a successful developer product.

I don't think their development weren't that bad in general. Ok, maybe Visual Basic was, but only because it was so easy to write bad code with it.