Dynamic languages are becoming more popular than ever. Static runtimes (static type system is baked into the machine) like the CLR do not natively support languages that have no requirement for explicit types. Implementing languages of this class on the
CLR is a rather complicated and arduous task. Some very clever folks like Program Manager, RubyCLR creator and IronRuby team member
John Lam and Senior Software Developer
Martin Maly (creator of the
LOLCode
programming language implementation that runs on the DLR, but more importantly one of the devs who writes the DLR) are on the team that makes implementing dynamic languages that can run on top of the CLR not only possible but easier than one might expect.
This is made possible with a new managed virtual machine called the
Dynamic Language Runtime (
DLR). The DLR runs on top of the CLR, but you can think of the DLR as it's own managed runtime (or virtual machine). For this interview, it is assumed that you
have working knowledge of what the CLR does.
This interview focuses deeply on one core question:
How does the DLR work. Of course, we talk about the history and future of the DLR, but primarily we find out about DLR nuts and bolts and architecure.
This interview is whiteboard heavy and compelling. It was really fun to chat with John and Martin and geek out on the DLR. It is a great technology with a very bright future.
Enjoy!
Low res file here.
Follow the Discussion
Oops, something didn't work.
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.sign up for email notifications?
LOLCODE on DLR
Codeplex the version you have!
LOLCODE on DLR
Codeplex the version you have!
What happenes with the no longer valid code? Like if the version gets up what happens with the no longer valid IL and tree. I understand that the tree just gets dumped but is there a concept to removed the jitted IL of a method, or how is this solved?
Let's say I have this + operation for int and int. Now the tree gets generated and some piece of IL and at the end the Help call. What if next comes in a + string string. Is the whole + int int regenerated or do you create the + string string IL in a method and add the call to the old + int int delegate at the end? Or are you holding like a list internally that holds all the delegates for the different + operations and you invoke them one by one?
In the fully dynamic mode, and if IL is generated (as opposed to the trees being interpreted), the IL is generated as CLR Dynamic Methods which are eligible for GC.
If I understand your second question correctly - the original site is replaced by the new site.
Ah! Seems like I had a blackout on the GC part... sorry.
Generating the new side means that you generate the whole IL for the + int int again (let's suppose the first side had already the code for the + int int in place and you add a + string string)? Isn't generating the new side going to be slow ower the time as you add new cases? I'm curious whether you guys have seeen performance decreases there... you probably did a lot of performance measurement...
Another thing: from time to time I'm using custom runtime code generating for the CLR too (like TypeBuilder, AssemblyBuilder, DynamicMethod, etc.). I wonder if you guys have public benchmarks on how fast/slow stuff is and/or guidelines that show us what should be avoided etc...
Thanks in advanced.
Good video, really scratches the surface
Any chance of seeing continuation of DLR discussion any time soon?
Also, if a dynamic language chooses to implement n-ary operators, then pathological cases may become not-so-pathological at all. Not that I'm aware of any such language, but still.
If I understand it correctly, the number of trees cached at a dynamic site is K^N (K being operators arity and N being number of types operation can be performed upon).
Currently DLR seems to rely on equivalents of IF…THEN statements to call proper implementation of the operator depending on the type of passed in arguments.
Wouldn't it make sense to allow dynamic language implementer (and presumably developer by proxy) to specify whether to rely on IF…THEN chains or use something like a hash table of delegates, where hash key will be produced using the list of operand types?
And finally, if adding apples to oranges is not a supported operation in a language and while asking the language DLR will get back an exception, will DLR try to "remember" that or on the next occurrence of add(apples, oranges) it will ask for help again? Shouldn't it be also somehow configurable?
What if it has the name of Dynamic Language Converter as .NET languages have lasted efforts of conversion tools? It's supposed to be a little risky to drive developers marketplace without real business interfaces of applications deployment scopes.
With comparison of .NET language converter, how does that DLR compliant definition including actions and invocation infrastructure save cost and performance?
Windows industry have presumably invested the first decade of Windows application runtimes which proved further language neutral and object oriented system. Long history of OLE software asset has following characteristics.
Web Services architecture and unfolding W3C XML activity related standards might propose such flexible runtime design. Also given subject of runtime invocation system is somewhat neural network and fuzzy software method to solve, but not seeing outright answers and industrial references.
What happened to Managed JScript?
From the team who invented it: The DLR JS was experimental for informing the design of the DLR. At this time there are no plans to develop and release a DLR-hostable JS
C
Remove this comment
Remove this thread
close