5 ms·

Microsoft previews Roslyn: .NET Compiler-as-a-Service infrastructure

46 points by lmkg 15y ago

chrisbennet 15y ago
I image keeping my development tool in Redmond ensure I keep paying fees but what does this do for developers?
- contextfree 15y ago
  This has nothing to do with tools running on a server. The "compiler as a service" phrase they were using apparently misled people into thinking it had something to do with "software as a service", which is why they aren't using it anymore. It's about allowing external programs to plug into the compiler pipeline and reuse its syntactic and semantic analysis capabilities.
- bjg 15y ago
  As mentioned in the link, there are two presentations you can view. Interesting demo during BUILD: http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-816T http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-816T You can skip to 35:40ish Cool presentation from MSR: http://research.microsoft.com/apps/video/?id=152281 http://research.microsoft.com/apps/video/?id=152281 You can skip to around 5:00
  - mullr 15y ago
    The build video is somewhat amusing to me. The crowd was WAY into the REPL demo, wherein they showed things that any dynamic language has been doing for decades, all the while trumpeting the "power of static typing". There IS power in static typing, but by the time you're in the REPL you don't need much of it.
    - ajanuary 15y ago
      I dunno, the reliability of Intellisense static typing gives combined with a REPL would be even more useful for exploration. That aside, it's exciting to have the ability to have both.
    - jules 15y ago
      Intellisense in a REPL based on static type information is novel, as far as I know. Some dynamic languages do this based on dynamic type information, but that is limited to expressions whose value is known. For example you have a variable A in scope at the REPL, and it has a method A.foo(), then you'll get completion on .foo. But you'll not get completion on A.foo().bar(), because the value of A.foo() is not known at the time of typing that expression.
- skrebbel 15y ago
  I was equally confused about this for a while. With SaaS in practice being "runs on the vendor's servers", I think "CaaS" is a badly chosen name. I think it's ridiculous to thumb down the parent just because he misunderstood this.
Jupe 15y ago
I think this is quite interesting. The ability to treat code as data is an incredibly powerful concept. I don't know exactly what Roslyn does, but I see a lot of potential: 1. Measuring code complexity. I've often felt that code complexity can be gauged several ways, and one is the number of "if" statements (or select..case). Being able to query the code base of an extremely large solution is a big step in that direction. 2. Being able to "query" the call stack - how do I get from this line to the base constructor of my "user" object. Rather than stepping through the debugger, it could be a query of the code base to find the path from here to there. 3. Detecting bit-rot. Finding any method class that's simply never used could be another "query" of the code base. Yes, proper test-coverage would help detect this, but not every production system has unit tests. 4. I've worked on projects in the past where we really wanted to add guid tracing to the preamble of each function to dynamically trace the code at run time. If Roslyn supports "update" queries of the code, it might be easy to add such a feature across the whole code base (or perhaps only classes that inherit from some known base class). Managing a code base like this (rather than grepping/searching) is a powerful concept. Perhaps we could see a LINQ for source code some day?
- SeveredCross 15y ago
  I agree with all of your points, though the only one I can address is the LINQ for source code quip and amend it somewhat to an already possible "LINQ for codebases." It should, in theory, be just a few weekends worth of work to use Mono.Cecil (https://github.com/jbevain/cecil https://github.com/jbevain/cecil) to provide a nice queryable API to inspect an (already compiled) codebase. I'm sure some nice static evaluation tools could be written based on this that nobody's thought of yet. That said, being able to inspect the source-code pre-compilation is a whole other level above and beyond—as a fan of the compile-time safety that statically-typed languages provide, any opportunity to eliminate bugs and complexity before the code makes it to a customer is a welcome one, and if Roslyn is good, it could be huge.
  - solutionyogi 15y ago
    Roslyn will be good. It has to be because from what I understand, the MS team themselves will use Roslyn in Visual Studio and other products. Roslyn isn't just a public API for others to analyze code. It will be the foundation on which .NET framework languages will depend upon. See Eric Lippert (Member of the Roslyn team, C# Principal) notes here: http://blogs.msdn.com/b/ericlippert/archive/2011/10/19/the-roslyn-preview-is-now-available.aspx http://blogs.msdn.com/b/ericlippert/archive/2011/10/19/the-r...
lmkg 15y ago
So I read Eric Lippert's blog post on Roslyn[1], where he says the motivation for the project was because other teams within Microsoft were re-implementing parts of the C# compiler piecemeal, so it made sense to expose those parts as an API. You know what that reminds me of? Steve Yegge's Platform rant. Specifically, the part where Bezos made Amazon convert all of their existing development infrastructure into services, that other units can make use of. That's what Roslyn is, on a much smaller scale: refactoring an application (the compiler) to be services-oriented platform. http://blogs.msdn.com/b/ericlippert/archive/2011/10/19/the-roslyn-preview-is-now-available.aspx http://blogs.msdn.com/b/ericlippert/archive/2011/10/19/the-r...
- mullr 15y ago
  Not really, no. It's more like a compiler as a library with a nice API.
  - barrkel 15y ago
    Libraries can be platforms too. Platforms are a mode of operating when providing, on an ongoing basis, something that third parties use. There are several "promises" around platforms: a promise not to break compatibility, a promise not to coopt client software features, and - oddly enough - a promise to be incomplete, so that third parties have opportunities to build.
  - scott_s 15y ago
    The authors certainly see it in this way: The transition to compilers as services dramatically lowers the barrier to entry for creating code focused tools and applications. From http://msdn.microsoft.com/en-us/hh500769 http://msdn.microsoft.com/en-us/hh500769 I agree with the parent. Yegge's platform rants is what I thought of, too.
- contextfree 15y ago
  Not only that, but iirc the project Steve Yegge is actually working on at Google is something along the same lines - a code analysis platform (for the JVM I think?)
equark 15y ago
If Rosyln is written in C# does this mean Roslyn can run on Mono?
duncan_bayne 15y ago
Interesting. Some years ago my business partner and I wrote a server in Ruby on Rails that used Mono to compile customised .NET assemblies on the fly. Worked very nicely for our problem domain but was ultimately scuppered by CAS workarounds.

46 points by lmkg 15y ago

chrisbennet 15y ago

I image keeping my development tool in Redmond ensure I keep paying fees but what does this do for developers?

contextfree 15y ago
This has nothing to do with tools running on a server. The "compiler as a service" phrase they were using apparently misled people into thinking it had something to do with "software as a service", which is why they aren't using it anymore. It's about allowing external programs to plug into the compiler pipeline and reuse its syntactic and semantic analysis capabilities.
bjg 15y ago
As mentioned in the link, there are two presentations you can view. Interesting demo during BUILD: http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-816T http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-816T You can skip to 35:40ish Cool presentation from MSR: http://research.microsoft.com/apps/video/?id=152281 http://research.microsoft.com/apps/video/?id=152281 You can skip to around 5:00
- mullr 15y ago
  The build video is somewhat amusing to me. The crowd was WAY into the REPL demo, wherein they showed things that any dynamic language has been doing for decades, all the while trumpeting the "power of static typing". There IS power in static typing, but by the time you're in the REPL you don't need much of it.
  - ajanuary 15y ago
    I dunno, the reliability of Intellisense static typing gives combined with a REPL would be even more useful for exploration. That aside, it's exciting to have the ability to have both.
  - jules 15y ago
    Intellisense in a REPL based on static type information is novel, as far as I know. Some dynamic languages do this based on dynamic type information, but that is limited to expressions whose value is known. For example you have a variable A in scope at the REPL, and it has a method A.foo(), then you'll get completion on .foo. But you'll not get completion on A.foo().bar(), because the value of A.foo() is not known at the time of typing that expression.
skrebbel 15y ago
I was equally confused about this for a while. With SaaS in practice being "runs on the vendor's servers", I think "CaaS" is a badly chosen name. I think it's ridiculous to thumb down the parent just because he misunderstood this.

Jupe 15y ago

I think this is quite interesting. The ability to treat code as data is an incredibly powerful concept. I don't know exactly what Roslyn does, but I see a lot of potential: 1. Measuring code complexity. I've often felt that code complexity can be gauged several ways, and one is the number of "if" statements (or select..case). Being able to query the code base of an extremely large solution is a big step in that direction. 2. Being able to "query" the call stack - how do I get from this line to the base constructor of my "user" object. Rather than stepping through the debugger, it could be a query of the code base to find the path from here to there. 3. Detecting bit-rot. Finding any method class that's simply never used could be another "query" of the code base. Yes, proper test-coverage would help detect this, but not every production system has unit tests. 4. I've worked on projects in the past where we really wanted to add guid tracing to the preamble of each function to dynamically trace the code at run time. If Roslyn supports "update" queries of the code, it might be easy to add such a feature across the whole code base (or perhaps only classes that inherit from some known base class). Managing a code base like this (rather than grepping/searching) is a powerful concept. Perhaps we could see a LINQ for source code some day?

SeveredCross 15y ago
I agree with all of your points, though the only one I can address is the LINQ for source code quip and amend it somewhat to an already possible "LINQ for codebases." It should, in theory, be just a few weekends worth of work to use Mono.Cecil (https://github.com/jbevain/cecil https://github.com/jbevain/cecil) to provide a nice queryable API to inspect an (already compiled) codebase. I'm sure some nice static evaluation tools could be written based on this that nobody's thought of yet. That said, being able to inspect the source-code pre-compilation is a whole other level above and beyond—as a fan of the compile-time safety that statically-typed languages provide, any opportunity to eliminate bugs and complexity before the code makes it to a customer is a welcome one, and if Roslyn is good, it could be huge.
- solutionyogi 15y ago
  Roslyn will be good. It has to be because from what I understand, the MS team themselves will use Roslyn in Visual Studio and other products. Roslyn isn't just a public API for others to analyze code. It will be the foundation on which .NET framework languages will depend upon. See Eric Lippert (Member of the Roslyn team, C# Principal) notes here: http://blogs.msdn.com/b/ericlippert/archive/2011/10/19/the-roslyn-preview-is-now-available.aspx http://blogs.msdn.com/b/ericlippert/archive/2011/10/19/the-r...

lmkg 15y ago

So I read Eric Lippert's blog post on Roslyn[1], where he says the motivation for the project was because other teams within Microsoft were re-implementing parts of the C# compiler piecemeal, so it made sense to expose those parts as an API. You know what that reminds me of? Steve Yegge's Platform rant. Specifically, the part where Bezos made Amazon convert all of their existing development infrastructure into services, that other units can make use of. That's what Roslyn is, on a much smaller scale: refactoring an application (the compiler) to be services-oriented platform. http://blogs.msdn.com/b/ericlippert/archive/2011/10/19/the-roslyn-preview-is-now-available.aspx http://blogs.msdn.com/b/ericlippert/archive/2011/10/19/the-r...

mullr 15y ago
Not really, no. It's more like a compiler as a library with a nice API.
- barrkel 15y ago
  Libraries can be platforms too. Platforms are a mode of operating when providing, on an ongoing basis, something that third parties use. There are several "promises" around platforms: a promise not to break compatibility, a promise not to coopt client software features, and - oddly enough - a promise to be incomplete, so that third parties have opportunities to build.
- scott_s 15y ago
  The authors certainly see it in this way: The transition to compilers as services dramatically lowers the barrier to entry for creating code focused tools and applications. From http://msdn.microsoft.com/en-us/hh500769 http://msdn.microsoft.com/en-us/hh500769 I agree with the parent. Yegge's platform rants is what I thought of, too.
contextfree 15y ago
Not only that, but iirc the project Steve Yegge is actually working on at Google is something along the same lines - a code analysis platform (for the JVM I think?)

equark 15y ago

If Rosyln is written in C# does this mean Roslyn can run on Mono?

duncan_bayne 15y ago

Interesting. Some years ago my business partner and I wrote a server in Ruby on Rails that used Mono to compile customised .NET assemblies on the fly. Worked very nicely for our problem domain but was ultimately scuppered by CAS workarounds.