Guest post by “Looking past the Metro hype, the Build conference also revealed promising road maps for C#, Visual Studio, and the .Net platform as a whole. Perhaps the most exciting demo of the conference for .Net developers, however, was Project Roslyn, a new technology that Microsoft made available yesterday as a Community Technology Preview. Roslyn aims to bring powerful new features to C#, Visual Basic, and Visual Studio, but it’s really much more than that. If it succeeds, it will reinvent how we view compilers and compiled languages altogether.”
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.
Right. Of course it will.
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.
Edited 2011-10-24 23:50 UTC
Oh, I don’t know… I learned a lot from working with QuickBasic and QuickC, back in the day. They might not have been great for serious developers, but were a very good way for a youngster to get started.
Don’t get me started on their web development tools, though. The ones included in IE8 and later are adequate, but it took them far too long to provide something that could match the least of what Firebug (and the WebKit equivalent) deliver.
Microsoft tools really just sort of sucked until they started the practice of just hiring away all the best engineers from their competitors.
You have to reach back to the early 90s — nearly 20 years ago — for that. And that’s quite frankly forever in technology terms.
Huh? This isn’t vapor. The CTP was released yesterday.
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.
Edited 2011-10-25 14:44 UTC
BS. I used VS, Watcom, *and* Borland tools, going back to the 80s. VS was already pretty well-integrated in the early 90s.
Right, said the pendantic.
I tend to disagree with that; comparing Visual Studio 6.0 with Borland C++ Builder 6.0 made Borland tools better, easier to use and more standard compliant than MS ones.
Actually, Visual C++ 6.0 had a very poor standard compliance if compared with Borland’s or GNU’s compilers.
And though this is a very biased comment, I consider MFC and COM (both MS technologies) ultraoverengineered and megacomplicated comparing to other alternatives available such days.
Edited 2011-10-25 22:54 UTC
If you only developed on the MS platform then you surely see progress. If not, you see everything they do as a never-ending charade with intention to steal your focus.
A Mono C# compiler with a REPL, wow that’s really revolutionary!
/sarcasm
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.
C64 basic was the worst part of the whole package. It was basically quite useless bearing the need for extensions as e.g. Simon’s Basic. The only positive parts were the extensibility and some interpretation speed parts.
True, but it started many passionate relationships. Turn on your computer today and type something like:
POKE 53272, 23
FOR I = 1 TO 10 : PRINT “Hello!” : NEXT
Not that easy, right? Once you got there, there was a clean, shiny assembly road in front of you, with every possible register documented in black and white. Today you’re lost in the woods and companies like MS with their shiny fcukups trying to lead you in their financial traps are not exactly helpful.
Microsoft BASIC was one of the worst variants going.
Plus nobody used BASIC for serious development, even back then and even on better BASIC implementations.
Developers wrote in machine code.
Visual Basic can be pretty much ignored as it’s pretty laughable for any serious development and Borland tools were significantly better than VS for quite some time. (IIRC I was still using Borland’s C++ Builder in the late 90s)
BASIC of Commodore line was rather poor. There were much better variants, BBC BASIC for example.
While wondering how many passionate relationships MS BASIC possibly started, consider also how many people it, perhaps, repulsed…
…and you’ve created a fully interactive read-eval-print loop (REPL) console for C#
hundreds of man-years / megabytes of code and finally we have something with the abilities of 53 years old Lisp.
RIP McCarthy 🙁
McCarthy died?!?!?!?!?
October is sad month. Steve Jobs, Dennis Ritchie, and now John McCarthy.
October was a happy month – then Ritchie and McCarthy died
+1
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?
I’m sure that .NET will be around for a long time for server development. But WinRT is the new Windows client API.
They’re not mutually exclusive, they both co-exist.
WinRT projects itself across the managed boundary. In fact, you can write WinRT components in .NET.
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.
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.
I hope that they do because I’ve read some of the cool features that help with battery/power efficiency and hope that maybe they’re down playing its use for desktop applications to give Metro all the lime light. I wonder whether we’ll see WinRT appear on Windows Phone 8 when it is released so then it will be possible to write native applications that scale from the laptop to the desktop then to the tablet and then to the phone.
That’s how I’m thinking they’ll do native code on Windows Phone actually, using the WinRT. Another thing I’d like is the concept of contracts to come to Windows Phone. It would be a game changer for the SDK in terms of how apps communicate.
I wish they’d copy Android a little in this regard, their intents paradigm is very nice.
I don’t know but the Windows 8 app store *idea* just makes me want to puke.
Sadly with Apple having such success with their mobile app store and now releasing the same fee charging ‘prison’ MS thinks this is the way to go.
I bet it makes development more expensive, and the returns to many developers will be lower.
Once Windows 8 hits with the app store I’ll basically make the full switch to the mac. If I have to deal with a walled garden, nazi run operating system then at least I should deal with the nicest one there is to use.
So what. Metro is the future of Windows. The desktop baggage is going to take a long time to die off, but there’s no reason why an average Win8 tablet user really has to deal with the desktop, if they’re running nothing but Metro apps.
They complement each other. WinRT is replacing Win32 not .Net.
.Net developers can also directly make access of WinRT APIs. It is still C#, VB.Net, F# and so on.
One of the good things of WinRT is that Hungarian notation is finally dead. Even Microsoft coding guidelines now advice against it, by calling a relic.
http://1code.codeplex.com/releases/view/53729#DownloadId=156490
Why do we need both of these? Or in other words, when would you use one instead of the other?
Here’s how it works:
WinRT is basically every Windows API (input, devices, graphics, networking, etc.) implemented in native C++.
C#, VB.NET, and Javascript are consumers of the WinRT API.
WinRT exports metadata files which describe its API. Using this metadata, lightweight bridges are automatically generated for .NET languages and Javascript.
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.
The concept is incredibly powerful, but not exactly groundbreaking.
Basically: .NET, Javascript, and C++ are all first class citizens when it comes to WinRT. There is no favoritism like before, where .NET had to do convuluted interop into unmanaged code, and Javascript did god knows what.
Its all very slick, and did I mention fast?
And nothing is preventing Microsoft of compiling .Net directly to native code instead om MSIL. like they do with Bartok/Spec# in Singularity.
I suppose. I don’t see why they’d want to. MSIL allows them to be platform independent.
And why would they need to be? Statistically speaking, they run on nothing else than x86.
x86, x64, and now with Windows 8, they will run on ARM.
Think forward. Who cares what they do now, an intermediate language allows them to support any arbitrary architecture in the future.
In addition, the JIT compiler can provide targeted optimizations for architecture specific things like SIMD.
I really shouldn’t have to be explaining the merits of an intermediate language, must you really complain about everything?
Yeah, seriously. He talks as if .NET runs MSIL directly instead of jitting it. It’s not exactly weird other. Other dynamic languages use bytecode. Even the C compiler internally generates assembly or some other type of intermediate language before turning it into machine code. This is a basic concept, a core component of nearly all compiled programming languages (and a lot of interpreted ones as well).
I complain so that you have something to post here
What is the WinRT ABI. Will C programs be able to access it or C++ is the new lowest common denomitator?
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.
With C++ you will have C++/CX or if you prefer only to use standard C++ the Windows Runtime Library.
With C you are stuck in the land of low level COM with the usual AddRef/Release, GUID and HRESULT macros.
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.
I think so, but I agree with this decision because it avoids code duplication. For example, they’ll write a great UI platform (WPF, or Silverlight) but then C++ and other langguages are out in the cold.
With WinRT, they ported XAML and all the graphics stack to C++ and exposed them as WinRT components, so C++ benefits from this awesome UI framework too.
The equality amonst the languages is what I love the most, and its why, even though I’m generally a hard ass, I’m willing to admit this is a better approach.
Previously they had an all-or-nothing thing going on, this is a little more encompassing. We’re all Metro developers now.
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.)
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.
Edited 2011-10-25 02:04 UTC
Hmm? you mean like llvm does?
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.
Not that its a bad thing, Roslyn is just ridiculously extensive. Its huge.
True. But it is not “revolutionary” either as the message I replied to put it. I am not even sure it is more flexible than llvm.
I did. I meant JavaC Compiler Tree API, not Compiler API.
That isn’t the same. This goes beyond creating syntax trees. The compiler plug-ins can manipulate the parse tree during compilation and completely alter the flow of the code through the compiler.
Ok. Then Eclipse JDT.
It is very cool and I am excited for it, but it has also been done already, making it less “revolutionary” than Microsoft’s marketing would have you believe. Someone has already mentioned Clang, but another example of excellent compiler engineering is Scala’s compiler. http://groups.google.com/group/scala-tools/browse_thread/thread/68e… is a mailing list post discussing and comparing Roslyn with Scala’s compiler framework.
Even if it isn’t that revolutionary, Roslyn represents the future of compiler architecture in general, and Microsoft’s efforts in this direction should be applauded.
Download it, play with it. It is so much more than that.
Its very interesting, and I don’t think anything quite like it has been done before, especially at runtime.
Lisp, Smalltalk…
Roslyn is so much more. You can hook into _every_ step of the compiler.
I’ve already seen pretty powerful stuff done with Roslyn the few days its been out. Things like adding custom extensions to the C# language (which are transformed at the syntax level, very cool).
There is just so much potential here its hardly conceivable the cool things you can do now.
No, this isn’t anything thats ever been done before.
You mean like Lisp macros?
Sure, Lispmacros can do that. That’s about it though.
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.
At least I, the only thing that I complain about is the language/tone: “If it succeeds, it will reinvent how we view compilers and compiled languages altogether.”.
That’s just crap, marketing talk.
That’s the way they should have say it. (Not sure if that’s too broken to be English, sorry.)
Even that isn’t true. This is something that has been done before (even in statically typed languages). Look at the Scala compiler.
Agreed, in C#/.NET it hasn’t been done before. Or maybe it has?
But outside .NET world it’s not something new.
PS: Did you know that GCC stands for GNU Compiler Collection?
Edited 2011-10-25 11:18 UTC
I guarantee you GCC can do nothing even close to this. Maybe LLVM+Clang (both of them, neither independently) can come close, but the richness of the APIs are not comparable.
Roslyn is alot more fleshed out than any other Compiler as a Service.
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.
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.
But again, none of that is something new. Is it new to .NET?
Within .NET community probably yes. Outside .NET, we’ll have to see.
LINQ: And yet, here I am 4 years later developing in every conceivable language outside of MS universe without LINQ making a dent.
Oh come on, you’re grasping at straws. Just because some of whats in Roslyn has been done before, in some fashion by some toolchains/languages doesn’t make it less innovative.
The innovation is in the sum of its parts, the execution, the conciseness, the ease of use. That’s never be done. Closest ones to get there before Roslyn is Clang, which I admire very much.
I suppose you also don’t think the iPhone was a game changer because phones, and screens, and buttons existed before, right? You’re being ridiculous.
There are over a dozen non .NET implementations of LINQ, either by name or concept, directly inspired from the work in .NET.
Being able to query anything a provider gives us using a declarative syntax is a game changer. That stands on its own, with or without your pet language implementing it.
LINQ equivalents do exist outside of the MS Universe (Haskell, Scala, etc.). The reason you don’t see it in many mainstream languages is because they lack language features required to implement it. However, many languages are starting to add features required to implement it (even C++ has lambdas now).
You could use this same description for Common Lisp and Slime. Although admittedly the implementation is actually somewhat different. However, this exact set of features has also been implemented in other languages use almost the exact same method. Look at the Scala presentation compiler and plug-in API. They’ve been around for at least a year. I believe the Eclipse Scala plugin already uses the presentation compiler.
This combination of features is not revolutionary. However, it is nice to finally see these features in a mainstream language.
I would argue that LINQ is not revolutionary either. It is just monad composition. This has existed in other languages for years. However, once again, it is nice to finally see these features in a mainstream language.
You know what, you may be right. I do appreciate going back and forth with you a great deal more, as I’ve actually learned something. I’ll look into those features.
However, the more you describe it, the more it looks like they are reinventing llvm.
What surprised you most is this syntax transformation thing. But it is obviously quite possible for any modern compiler because it just translates the AST representation of a program back into same/another language.
http://www.osnews.com/permalink?494275
Like Lisp Macros, Smalltak image changes, Groovy AST, and so forth?
Just because Microsoft PR makes it sound new, it does not mean it is.
No. Each of those only deal with one aspect of Roslyn. None of them do it all. Especially not lisp, come on dude.
Download the CTP, take it for a spin.
Ah, so MS took several good ideas from elsewhere and then threw them in the mixing bowl. I see.
Hehe, +5!
Great… now we can have compile time monkey patching so projects will be even more locked to Microsoft. I don’t want it.
If I download it it will be useless waste of bandwidth and space. I’m on Linux, you see…
Too bad, Microsoft doesn’t produce dev tools for other platforms.
Who can blame them, when you demonize the people who do? The Linux community in general treat the Mono guys like shit.
Yes, they are absolute angels that have never done or said anything anti-OSS or anti-Linux.
Mono guys aren’t treated like anything, they are just plain ignored. But in the same Linux community everyone is ignored, if that person or group keeps quiet.
I think back in the day, GCC developers have split the compiler into libs that allowed to access intermediate representation of (now guessing) syntax tree and rtl. As far as I know KDevelop devs are using that to implement code completion.
I heard about this, I can only wonder what the state of it today is.
nope KDevelop uses its own parser (which is also uses by QtCreator and some of the Qt/KDE bindings). They tried to use gcc-xml, but for some reason it was not working so well.
Probably it didn’t deal with syntax errors the way that dynamic editor requires. Anyway with GCC you have access to intermediate representation that is common to all language frontends and can use it to utilize GCC optimizer for your own languages.