I believe project Roslyn is a watershed moment. It will start a complete redefinition of what programming and being a computer programmer means.

But why? How could rewriting the Visual Basic and C# compilers be even a blip in the history of computer programming? At best it’s a sneeze!

Show me a computer program. Right now. Really. At least think through how you would show me.

OK, you just opened up an instance of Visual Studio and showed me Solution Explorer graph of a whole bunch of files. Text.

A small minority of you might have used a different approach –showing me functional tests, a user interface, a database or a dependency graph. An even smaller minority might have shown me a UML diagram, DSL, or other code generation metadata. Six or seven of you might have even opened a decompilation tool or showed me some IL. Two or three of you might have discussed semantics. One of you, just maybe, opened a workflow designer (ah, the sad story of Workflow is for another day).

The line between these realities has been stark. You’re writing code or your ditzing around with the tools that support you writing code. Text. Text. Text.

A computer program has always been all of these things and something else. Something ethereal that existed between your ears and my ears. As programs have become more complex, we become increasingly desperate to live in the ecosystem of our application instead of in the code. That’s what agile was all about. Agile makes our application into an ecosystem of players. So does DSL. But in both cases we’re blind and playing with only parts of the elephant.

Wait, code matters. Of course code matters! It is one expression of abstraction along the pipeline from idea to electrons moving in silicon. Code is the last thing that normal humans will comprehend. It becomes IL that a platform specific compiler understands, and then some magic happens. That end works. With apologies for the analogy, we know how to take the elephants output and fertilize the garden. The apps work. We just feed the elephants badly because we do not understand them.

Oh, just forget that analogy, it was gross anyway.

What we need to understand is that no one today understands what an application is. We can’t. We can’t because the way we reason about anything is predetermined by the wiring of how we sense it. To understand what applications are in new ways, we need new ways to sense them, redefine what they are and place them in rich ecosystems with no rigid boundaries of definition between problem and solution. It’s easiest to visualize as no rigid boundaries between text and graphics, but that will feel like a very shallow distinction within five years.

While no one understands what an application is today, no one can stop us coming to a new understanding and a new relationship in the next five years. Roslyn is not birthing in a vacuum. We have relatively mature ecosystems in DSL and functional languages. We have an emerging (about to be exploding) work happening in composition and semantics. We have ongoing research in algorithms. We have a lot of work in the areas of agile, quality, reasoning/diagraming, requirements, human interfaces, etc. We are ready.

Roslyn, for us in the .NET world, is the snowball tossed to start the avalanche of change. It will do this because it will lead us to think of our code as a semantic tree. Such a tiny, tiny thing. And then we’ll have the most amazing array of IDE tools, and then new DSL/generation tools, and then amazing new composition reasoning, and then…, and then… , and then… , and then… , and then… Each will lead us to new thinking about the next and around the tenth or hundredth “and then” it will be obvious how seismic the shift.

3 thoughts on “Roslyn”

  1. Actually it’s not the first time MS did something for the subject. I personally used MGrammar (formerly Oslo, Sql Modelling CTP, now on hold) to create self modifying (such way context sensitive) grammars, completely dynamic rule engine storing its code as data in a pretty DSL… all the enthusiastics have a look at it.


  2. I just read the above article twice in a hope I would gain a better understanding of what roslyn is used for, I came out confused, feeling like I have been handed a riddle in the form of poetic marketing buzz.

    Can you explain what roslyn is to a person who has built custom languages and multiple compilers? Yes I have written “applications” that manifest as an exe on your hard drive and convert text into machine byte code. What makes a compiler in the could different is what I want to understand, otherwise it sound like the time Microsoft made the “M” language, or EntitySpaces, or the myriad of fascinating projects that ultimately went nowhere. Sorry for the harsh tone

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>