Linked by twitterfire on Mon 24th Oct 2011 22:52 UTC
General Development "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."
Order by: Score:
Always is a very long time...or not.
by Soulbender on Mon 24th Oct 2011 23:50 UTC
Soulbender
Member since:
2005-08-18

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


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.

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


Right. Of course it will.

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.


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

Reply Score: 9

Delgarde Member since:
2008-08-19

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.


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.

Reply Score: 2

Bill Shooter of Bul Member since:
2006-07-14

Microsoft tools really just sort of sucked until they started the practice of just hiring away all the best engineers from their competitors.

Reply Score: 2

tomcat Member since:
2006-01-06

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.


You have to reach back to the early 90s -- nearly 20 years ago -- for that. And that's quite frankly forever in technology terms.

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.


Huh? This isn't vapor. The CTP was released yesterday.

Reply Score: 2

Soulbender Member since:
2005-08-18

You have to reach back to the early 90s


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

And that's quite frankly forever in technology terms.


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

Edited 2011-10-25 14:44 UTC

Reply Score: 3

tomcat Member since:
2006-01-06

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


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

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


Right, said the pendantic.

Reply Score: 2

ebasconp Member since:
2006-05-09

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


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

Reply Score: 3

marafaka Member since:
2006-01-03

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.

Reply Score: 2

tuma324 Member since:
2010-04-09

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.


A Mono C# compiler with a REPL, wow that's really revolutionary!

/sarcasm

Reply Score: 2

sithlord2 Member since:
2009-04-02


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.


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.

Reply Score: 0

dsmogor Member since:
2005-09-01

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.

Reply Score: 3

marafaka Member since:
2006-01-03

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.

Reply Score: 2

Laurence Member since:
2007-03-26



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.

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.

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.

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)

Reply Score: 3

zima Member since:
2005-07-06

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...

Reply Score: 2

Comment by viton
by viton on Mon 24th Oct 2011 23:58 UTC
viton
Member since:
2005-08-09

...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 :-(

Reply Score: 10

RE: Comment by viton
by broken_symlink on Tue 25th Oct 2011 01:44 UTC in reply to "Comment by viton"
broken_symlink Member since:
2005-07-06

McCarthy died?!?!?!?!?

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

Reply Score: 3

v RE[2]: Comment by viton
by f0dder on Tue 25th Oct 2011 22:56 UTC in reply to "RE: Comment by viton"
RE: Comment by viton
by marafaka on Fri 28th Oct 2011 08:36 UTC in reply to "Comment by viton"
marafaka Member since:
2006-01-03

+1

Reply Score: 2

.NET
by WorknMan on Tue 25th Oct 2011 01:03 UTC
WorknMan
Member since:
2005-11-13

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?

Reply Score: 2

RE: .NET
by tomcat on Tue 25th Oct 2011 01:57 UTC in reply to ".NET"
tomcat Member since:
2006-01-06

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.

Reply Score: 2

RE[2]: .NET
by Nelson on Tue 25th Oct 2011 03:12 UTC in reply to "RE: .NET"
Nelson Member since:
2005-11-29

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.

Reply Score: 2

RE[2]: .NET
by kaiwai on Tue 25th Oct 2011 03:34 UTC in reply to "RE: .NET"
kaiwai Member since:
2005-07-06

"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.
"

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.

Reply Score: 2

RE[3]: .NET
by Nelson on Tue 25th Oct 2011 13:49 UTC in reply to "RE[2]: .NET"
Nelson Member since:
2005-11-29

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.

Reply Score: 2

RE[4]: .NET
by kaiwai on Tue 25th Oct 2011 14:11 UTC in reply to "RE[3]: .NET"
kaiwai Member since:
2005-07-06

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.

Reply Score: 2

RE[5]: .NET
by Nelson on Tue 25th Oct 2011 14:16 UTC in reply to "RE[4]: .NET"
Nelson Member since:
2005-11-29

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.

Reply Score: 2

RE[4]: .NET
by Bit_Rapist on Wed 26th Oct 2011 14:44 UTC in reply to "RE[3]: .NET"
Bit_Rapist Member since:
2005-11-13

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.

Reply Score: 3

RE[3]: .NET
by tomcat on Tue 25th Oct 2011 20:48 UTC in reply to "RE[2]: .NET"
tomcat Member since:
2006-01-06

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.


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.

Reply Score: 2

RE: .NET
by moondevil on Tue 25th Oct 2011 07:00 UTC in reply to ".NET"
moondevil Member since:
2005-07-08

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.

.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

Reply Score: 2

RE[2]: .NET
by WorknMan on Tue 25th Oct 2011 07:25 UTC in reply to "RE: .NET"
WorknMan Member since:
2005-11-13

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


Why do we need both of these? Or in other words, when would you use one instead of the other?

Reply Score: 2

RE[3]: .NET
by Nelson on Tue 25th Oct 2011 07:36 UTC in reply to "RE[2]: .NET"
Nelson Member since:
2005-11-29

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?

Reply Score: 2

RE[4]: .NET
by moondevil on Tue 25th Oct 2011 12:11 UTC in reply to "RE[3]: .NET"
moondevil Member since:
2005-07-08

...
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.

...


And nothing is preventing Microsoft of compiling .Net directly to native code instead om MSIL. like they do with Bartok/Spec# in Singularity.

Reply Score: 2

RE[5]: .NET
by Nelson on Tue 25th Oct 2011 12:38 UTC in reply to "RE[4]: .NET"
Nelson Member since:
2005-11-29

I suppose. I don't see why they'd want to. MSIL allows them to be platform independent.

Reply Score: 2

RE[6]: .NET
by JAlexoid on Tue 25th Oct 2011 13:19 UTC in reply to "RE[5]: .NET"
JAlexoid Member since:
2009-05-19

And why would they need to be? Statistically speaking, they run on nothing else than x86.

Reply Score: 2

RE[7]: .NET
by Nelson on Tue 25th Oct 2011 13:47 UTC in reply to "RE[6]: .NET"
Nelson Member since:
2005-11-29

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?

Reply Score: 2

RE[4]: .NET
by dsmogor on Tue 25th Oct 2011 16:30 UTC in reply to "RE[3]: .NET"
dsmogor Member since:
2005-09-01

What is the WinRT ABI. Will C programs be able to access it or C++ is the new lowest common denomitator?

Reply Score: 2

RE[5]: .NET
by Nelson on Tue 25th Oct 2011 18:35 UTC in reply to "RE[4]: .NET"
Nelson Member since:
2005-11-29

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.

Reply Score: 2

RE[6]: .NET
by moondevil on Wed 26th Oct 2011 05:39 UTC in reply to "RE[5]: .NET"
moondevil Member since:
2005-07-08

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.

Reply Score: 2

RE[4]: .NET
by dsmogor on Tue 25th Oct 2011 16:44 UTC in reply to "RE[3]: .NET"
dsmogor Member since:
2005-09-01

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.

Reply Score: 2

RE[5]: .NET
by Nelson on Tue 25th Oct 2011 18:37 UTC in reply to "RE[4]: .NET"
Nelson Member since:
2005-11-29

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.

Reply Score: 2

I'm sorry, but how is this new?
by JAlexoid on Tue 25th Oct 2011 01:16 UTC
JAlexoid
Member since:
2009-05-19

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.)

Reply Score: 2

RE: I'm sorry, but how is this new?
by tomcat on Tue 25th Oct 2011 01:56 UTC in reply to "I'm sorry, but how is this new?"
tomcat Member since:
2006-01-06

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

Reply Score: 3

roverrobot Member since:
2006-07-23

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.


Hmm? you mean like llvm does?

Reply Score: 1

Nelson Member since:
2005-11-29

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.

Reply Score: 2

roverrobot Member since:
2006-07-23

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.


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.

Reply Score: 1

JAlexoid Member since:
2009-05-19

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

Reply Score: 2

tomcat Member since:
2006-01-06

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.

Reply Score: 2

JAlexoid Member since:
2009-05-19

Ok. Then Eclipse JDT.

Reply Score: 2

sreque Member since:
2010-09-10

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.

Reply Score: 1

RE: I'm sorry, but how is this new?
by Nelson on Tue 25th Oct 2011 03:13 UTC in reply to "I'm sorry, but how is this new?"
Nelson Member since:
2005-11-29

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.

Reply Score: 2

moondevil Member since:
2005-07-08


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


Lisp, Smalltalk...

Reply Score: 2

Nelson Member since:
2005-11-29

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.

Reply Score: 4

permafrosty Member since:
2011-10-25

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


You mean like Lisp macros?

Reply Score: 2

Nelson Member since:
2005-11-29

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.

Reply Score: 2

BiPolar Member since:
2007-07-06

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.


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.


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.


That's the way they should have say it. (Not sure if that's too broken to be English, sorry.)

Reply Score: 3

eeperson Member since:
2011-10-25

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.


Even that isn't true. This is something that has been done before (even in statically typed languages). Look at the Scala compiler.

Reply Score: 1

JAlexoid Member since:
2009-05-19

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

Reply Score: 2

Nelson Member since:
2005-11-29

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.

Reply Score: 1

JAlexoid Member since:
2009-05-19

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.

Reply Score: 3

Nelson Member since:
2005-11-29

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


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'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.


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.

Reply Score: 2

moondevil Member since:
2005-07-08

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


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.

Reply Score: 4

Nelson Member since:
2005-11-29

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.

Reply Score: 2

foregam Member since:
2010-11-17

Ah, so MS took several good ideas from elsewhere and then threw them in the mixing bowl. I see.

Reply Score: 0

marafaka Member since:
2006-01-03

Hehe, +5!

Reply Score: 2

FunkyELF Member since:
2006-07-26

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


Great... now we can have compile time monkey patching so projects will be even more locked to Microsoft. I don't want it.

Reply Score: 1

JAlexoid Member since:
2009-05-19

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.

Reply Score: 2

Nelson Member since:
2005-11-29

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

Reply Score: 5

JAlexoid Member since:
2009-05-19

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.

Reply Score: 1

RE: I'm sorry, but how is this new?
by dsmogor on Tue 25th Oct 2011 16:33 UTC in reply to "I'm sorry, but how is this new?"
dsmogor Member since:
2005-09-01

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.

Reply Score: 2

Nelson Member since:
2005-11-29

I heard about this, I can only wonder what the state of it today is.

Reply Score: 2

cyrilleberger Member since:
2006-02-01

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.

Reply Score: 2

dsmogor Member since:
2005-09-01

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.

Reply Score: 2