Microsoft's New Dynamic Language Runtime

azura4의 이미지

루비나 파이썬의 활용 범위가 더 넓어질 것 같네요. 정말 반가운 소식입니다.

원문은 http://blogs.msdn.com/hugunin/archive/2007/04/30/a-dynamic-language-runtime-dlr.aspx

A Dynamic Language Runtime (DLR)
Today, at MIX 07, we announced a new level of support for dynamic languages on .NET that we're calling the DLR.

From the beginning, Microsoft's .NET framework was designed to support a broad range of different programming languages on a Common Language Runtime (CLR). The CLR provides shared services to these languages ranging from a world-class GC and JIT to a sandboxed security model to tools integration for debugging and profiling. Sharing these features has two huge benefits for languages on the CLR. First, it's easier to implement a language because lots of difficult engineering work is already done for you. Second, and more importantly, these languages can seamlessly work together and share libraries and frameworks so that each language can build on the work of the others.

The CLR has good support for dynamic languages today. IronPython-1.0 demonstrates this. The new Dynamic Language Runtime (DLR) adds a small set of key features to the CLR to make it dramatically better. It adds to the platform a set of services designed explicitly for the needs of dynamic languages. These include a shared dynamic type system, standard hosting model and support to make it easy to generate fast dynamic code. With these additional features it becomes dramatically easier to build high-quality dynamic language implementations on .NET. More importantly, these features enable all of the dynamic languages which use the DLR to freely share code with other dynamic languages as well as with the existing powerful static languages on the platform such as VB.NET and C#.

The DLR is about giving you the best experience for your language - true to the language, excellent tools, performance and seamless integration with a wealth of libraries and platforms. The essential benefits of the DLR are about sharing. It lets language implementers share standard features rather than rebuilding them from scratch. This lets them focus on the features that make a given language unique rather than on reinventing yet another GC system. It lets developers share code regardless of the language the code is implemented in and to use whatever language they prefer regardless of the language preferred by the environment they want to run in. Coupled with the Silverlight 1.1 platform announced today, it even lets languages share a sandboxed security model and browser integration. This means that developers building browser-based applications can now use their preferred language even for client-side code.

We're initially building four languages on top of the DLR - Python, JavaScript (EcmaScript 3.0), Visual Basic and Ruby. We shipped today both Python and JavaScript as part of the Silverlight 1.1alpha1 release today. John Lam and I will be demoing all four languages, including VB and Ruby, working together during our talk tomorrow at 11:45.

In addition to the Silverlight release, we've also made the full source code for both IronPython and all of the new DLR platform code available on codeplex under the BSD-style Microsoft Permissive License. All of that code can be downloaded today as part of the IronPython project at codeplex.com/ironpython. If you want to know more about the DLR, you should feel free to download the code. However, you should understand that this is a very early release of these bits and we still have significant work left to do including refactoring, design changes, performance tuning - not to mention documentation.

For the short term, our focus is on using a small number of languages to drive the first wave of DLR development where we can work closely and face-to-face with the developers in order to iron out the worst kinks in the DLR design. After this initial phase, we want to reach out to the broader language community. If you're building a language on top of .NET and are interested in supporting dynamic language features then we want your feedback on the DLR. However, I'd discourage you from trying to implement on top of the DLR today. I don't want you to get frustrated trying to work with these really early bits and then not be interested in working with us when we're better prepared to engage with the language community. We plan to kick off a broader engagement with language implementers at the upcoming lang.net conference in three months - at the end of July. This will be the best place to really engage with the DLR and let us know what we got wrong.

In the meantime, I'll be using this blog to post our design notes for the DLR as they're written and any feedback you have on the design is welcomed. Tomorrow I'll talk more about the shared dynamic type system and the "One True Object".

aero의 이미지

그동안 Java의 JVM, .NET의 CLR 같은 VM이 있었으나 이것들은
Static typed language에 적합한 구조로 .NET위에 Python,Ruby를 올린 IronPython,IronRuby같은 것들이 개발되어 있기는 하지만 Perl,Python,Ruby 같은 Dynamic typed language를 100% 지원하기에는 힘든 구조였습니다.
이에 오픈소스계의 Perl진영에서는 Perl 6을 올릴 Parrot이라는 Dynamic typed language에 적합한 VM을 개발중에 있지요 아직 가야할 길은 좀 있어보입니다만...

그런데 MS에서 이번에 CLR에 Layer형식으로 DLR이란걸 만들어서 Dynamic typed language를 더욱 효율적으로 지원하도록 만들었습니다.
DLR에 현재 구현되어있는것은 Python,Ruby,Javascript,VisualBasic이라고 합니다.
다른것들도 DLR위에 구현만 하면 Parrot이 지향하고 있는바 처럼 여러언어들을 손쉽게 같이 쓸 수 있게 되는거죠 나아가서는 CLR위에서 구현된 C#등의 언어와의 연동까지....
Silveright라는건 Rich web을 지원하기 위한 Adobe flash+alpha의 형태를 띄는 MS제품인데
이것은 멀티플랫폼을 지향하고 있고 DLR도 이것과 연동되어서 돌아가기 때문에 DLR에 위헤 구현된 언어이면 web에서 많이 쓰는 javascript대신에 제어언어로 사용가능하게 됩니다.

이번 DLR 시연도 MacOS X에서 이루어진것으로 보아 LINUX를 포함한 멀티플랫폼도 지원하게 될것으로 보입니다. 소스도 BSD스타일 비슷한 라이센스로 풀거라고하고...

MS가 빠른개발 속도로 유행이 되어가는 Dynamic typed language들의 하부구조를 선점하기 위해 한 방 터뜨렸다고 볼 수 있을것 같군요.

익명사용자의 이미지

http://www.onjava.com/pub/a/onjava/2006/04/26/mustang-meets-rhino-java-se-6-scripting.html

Java의 디테일한 지원능력이나 DLR의 구현정도의 차이를 전문적으로 알고 있는 것은 아니어서
자세하게 논할 수는 없으나
Java6에는 이미 JavaScript마저 기본 포함되어 있습니다.

덕분에 예전에는 JavaScript와 Java는 아무관계없다고 강조(?)했지만
이제 아무관계없는 사이도 아니죠.

MS가 터뜨렸다기보단 트렌드를 따라가는 느낌이죠.

feanor의 이미지

Java 6에 포함된 JavaScript와 비교하자면, DLR은 동적 언어가 정적 언어의 라이브러리에 접근하는 것 뿐 아니라 (이건 Rhino에서도 잘 됩니다) 동적 언어 상호간에 라이브러리를 호출할 수 있게 하는 데에 포인트가 있습니다. "트렌드를 따라가는" 것이라고 보기에는 좀 무리가 있습니다.

Java 위에 올라가는 동적 언어들이 사용하는 adapter 패턴과, DLR이 사용하는 navigator 패턴의 차이점과, 왜 후자의 패턴이 동적 언어 상호간 호출에 더 유리한지는 아래 글이 잘 설명하고 있어 소개합니다.

http://www.szegedi.org/articles/wrappersOrNavigators.html

익명사용자의 이미지

아~ 스크립트 상호간 라이브러리를 접근하는 부분에서 차이가 있는 것이로군요.

사용하기 좋은 스크립트언어와
이미 잘 갖춰진 GC 및 라이브러리를 지니고 있는 .NET이나 Java와의 결합
이라는 측면만 생각했었는데

그런 부분(구현된 스크립트 상호간의 라이브러리 호환)도 있었군요.
좋은 정보 감사드립니다.