Future of IronPython and others languages based on DLR

Feb 3, 2010 at 11:32 AM

Hello.

What is the future of the DLR and IronPython?
Will there be in the near future, the same that happened with JScript?
Does it make sense to use these technologies to develop long-time  projects?

Microsoft makes no warranties, extending the product under the Public Licence. I fear that Microsoft will say "Sorry! It's an experimental technology".

Thank you.

Feb 3, 2010 at 12:55 PM

Microsoft burried JScript, because they needed to hook python developers (from the other side of programming).

JScript wouldn't make sense for them.

There is a strive at Microsoft to convert everybody to Microsoft religion, but in this effort the very users of Microsoft technologies are forgotten...

 

Feb 3, 2010 at 12:57 PM

And more, I would have expected from microsoft to produce an extra layer over DLR,

a layer that will make easy to implement any language, not necessary python.

This would be something really special.

 

 

Feb 3, 2010 at 1:29 PM

ursuletzo: Another layer, on-top of the DLR? I managed to implement a fully working version of JavaScript in about 3½ weeks (albeit it's a bit slow, but what can you expect after such a short period of time). This included learning the DLR from pretty much scratch. The DLR is in no way tied to IronPython - thought IronPython is the driving force behind the DLR, they are pretty much detached from each other, it fits equally good for IronRuby, IronScheme, Clojure-CLR or my own language IronJS - or even the new dynamic keyword in C#, which also uses the DLR.

I don't see how MS could make it any easier to build a language on the DLR without pretty much sacrificing everything that makes the DLR good (incredibly flexible, decently fast, easy to learn, incredibly nice API). I don't mean to come of as rude, but this really got me annoyed. The DLR is incredibly easy to use compared to the alternatives (writing your own runtime from scratch in C/C++, writing your own dynamic language runtime on top of the CLR).

Feb 3, 2010 at 1:51 PM

hi fholm.

Did you implement debugging support and closures ?

 

 

Feb 3, 2010 at 2:07 PM

Yes, closures is a requirement for it being a JavaScript implementation :)

I also have an early version of visual studio debugging on my local working copy.

Why?

Feb 3, 2010 at 2:36 PM

Regarding my extra layer:

Is there a difference between looping and conditional constructs between languages?

Is there a difference between functions?

Is there a difference between closures?

And what about locals, and scope resolution

Why does each language developer need to write the same things again from scratch?

 

Feb 3, 2010 at 2:45 PM
Edited Feb 3, 2010 at 2:51 PM

Is there a difference between looping and conditional constructs between languages?
There can be, but mostly - no, and that's why you have: IfThen, IfThenElse and Condition expressions in the DLR. (Edit: You also have LoopExpression for generic loops)

Is there a difference between functions?
Again, there can be (especially how they are treated, like objects? like first class values? like statements? but also how they are called, implicit and explicit parameters, etc.), but again - mostly no. And that's why you have LambdaExpression in the DLR

Is there a difference between closures?
Most definitely, yes. The general idea is the same, but they do differ amongst languages. But the DLR already supports automatic closures with it's LambdaExpression

And what about locals, and scope resolution
This differs a lot between languages, how locals and scope is treated vary greatly between Python and JavaScript, and even more if you mix in s-expression languages

Why does each language developer need to write the same things again from scratch?
Because while the basic concepts are the same, the exact implementation details for each language differ a lot from each other. The DLR team has done an awesome job in abstracting as much away as possible, without limiting what you can do. It's a perfect balance if I ever saw one.

Feb 3, 2010 at 3:11 PM

I agree they did ( the DLR team) a good job.

I myself have implemented a custom language on top of dlr...

What i felt is a lack of guidelines and decent documentation other than the code itself, of course.

 

 

 

Feb 3, 2010 at 4:23 PM
I am the implementer of ASP Classic Compiler (http://aspclassiccompiler.codeplex.com) and I would say that DLR has significantly lowered the bar of implementing a language. This is a pet project for my spare time and I only have a few hours a week on it; I would not take on a project like this if I would have to generate IL directly. The dynamic metaobject binder architecture is quite flexible. I had to work out a few things like pass-by-ref but never hit a wall.
 
The document is difficult to understand in the first read but I was able to understand it after reading it several times. I hope somebody will write a easier to understand book. I also hope that the DLR team will document the Microsoft.Scripting.Debugging namespace as well as the Silverlight integration.
 
The runtime memory management of my VBScript.net compiler is different to other dynamic languages. While most dynamic languages allow dynamic membership (i.e., adding/deleting members in scope at runtime), I went with static membership (for indices kind of access rather than dictionary kind of access) because I tried to make it run fast as it is executed on servers. So far it is several times faster than the ASP Classic that comes with IIS for several reasons. All I try to say is language implementers need flexibility to implement what they need and I think DLR has the pieces for that.

On Wed, Feb 3, 2010 at 7:11 AM, ursuletzu <notifications@codeplex.com> wrote:

From: ursuletzu

I agree they did ( the DLR team) a good job.

I myself have implemented a custom language on top of dlr...

What i felt is a lack of guidelines and decent documentation other than the code itself, of course.

 

 

 

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Feb 3, 2010 at 6:02 PM

While this thread has turned into a bit of a love fest for the DLR (which is great) I’d like to come back to the original question.

The DLR comes in 2 different parts: the inner and outer layers.  The inner layer ships with .NET 4.0 and has all the normal support guarantees.  The outer layer is a work in progress and as we stabilize components there our intention is to bring them into the .NET framework where they’ll be trivially available to all language implementers (versus needing to re-distribute various DLR components).  So that’s the basic plan there.

IronPython continues to be developed – we’re working on putting out our 2.6.1 soon along with an updated release for .NET 4.0.  We’ve started talking internally about what our plans for our next major versions are as well.  And we continue to talk about other ways we can enhance our users experience with IronPython – if you’d like to see something in particular, even if it’s not technical like “This should be PSS supported”, we’d love to hear your feedback.  You can expect that we’ll get more concrete about our future plans at PyCon later this month.

Microsoft of course reserves the right to cancel any project at any point in time – look at Flight Simulator, who could have seen that coming?  So is there a guarantee you’ll get bug fixes for the next 10 years?  No.  Is it getting cancelled tomorrow?  Nope, that’s not going to happen either. 

From: darrin [mailto:notifications@codeplex.com]
Sent: Wednesday, February 03, 2010 3:32 AM
To: Dino Viehland
Subject: Future of IronPython and others languages based on DLR [dlr:82995]

From: darrin

Hello.

What is the future of the DLR and IronPython?
Will there be in the near future, the same that happened with JScript?
Does it make sense to use these technologies to develop long-time projects?

Microsoft makes no warranties, extending the product under the Public Licence. I fear that Microsoft will say "Sorry! It's an experimental technology".

Thank you.

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Coordinator
Feb 3, 2010 at 6:16 PM

We are constantly adding layers which make it easier to implement languages.  In fact we call the core of the DLR which is shipping in .NET 4.0 the “inner layer” and the rest of the DLR the “outer layer”.  That includes:

                A DLR expression tree interpreter and adaptive compiler so languages can benefit from improved startup time by reducing JITing

                A default and extensible overload resolver to make it easy to implement binding to .NET methods

                A default and extensible binder which makes it easy to implement binding to .NET objects from call sites

                A debugging API which makes it easy to re-write method bodies so that their locals live in the heap and there execution can be removed from the stack

                A hosting API which enables applications to talk to one API and host multiple languages

               

We’re missing anything related to parsing and tokenization but hopefully M Grammar fills the role there.  What else do you think we should provide?  Which of these would you like to see moved to the .NET framework first?

From: ursuletzu [mailto:notifications@codeplex.com]
Sent: Wednesday, February 03, 2010 4:57 AM
To: Dino Viehland
Subject: Re: Future of IronPython and others languages based on DLR [dlr:82995]

From: ursuletzu

And more, I would have expected from microsoft to produce an extra layer over DLR,

a layer that will make easy to implement any language, not necessary python.

This would be something really special.

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Feb 3, 2010 at 6:28 PM

I must also come to the defense of the DLR team on this one.

I've implemented an ECMAScript variant for use in my company's core product, using the DLR. Yes it was hard at first, and yes the documentation can be sparse in places. It's taken a while for me to really grok the design and the moving parts. But the alternatives are far worse. And implementing a language is a hard problem... make that, a hard set of problems, and there's no secret sauce (DLR or other) to make it easy.

As I see it, DLR's design is principally about four things:

1. provide abstractions for binding arbitrary logic constructs on the front end to arbitrary execution semantics on the back end

2. provide abstractions for meaningful interop between languages riding on top of it

3. peripheral stuff like hosting which is useful for some but not all implementations

4. make 1-3 as fast and memory-efficient as it can be  :-)

On those counts, I consider DLR a huge success. In fact, we've had such success with our ECMAScript-esque implementation that we've decided to use DLR for a lot more things in a forthcoming version of our product.

The fact that DLR is now baked into the BCL (and C# and VB utilize it for their dynamic capabilities) is reason enough to assume it's not going away anytime soon. It's fair to consider what additional resources MS will devote to it... but again, I think being a dependency on C# will help ensure it gets some continuing love. And if you ask me, there are lots of interesting things to do with DLR that have nothing directly to do with building languages per se... I'd like to see some emphasis on those aspects (think more emphasis on item 1 above, and less on item 2). But that's just me.  :-)

As for IronPython and IronRuby... who knows, but:

1. it would be bad PR if MS got rid of them... doesn't mean they won't, but it's an important reason they must consider

2. you've got the source regardless... if lack of future support scares you that much, you should probably stick with C# or VB

But if you have any desire to map metadata (of various forms) to execution on the CLR, DLR is by far the best game in town.

Josh

 

Feb 4, 2010 at 2:16 PM

Thank you all for your answers.

I started this thread, that would be determined by the future of project of our company. Development began when the last available version of Managed JScript was released. JScript was chosen as the scripting language, since the syntax of JScript is more familiar to developers. Managed JScript is not Open Source project, so I thought that Microsoft did not drop it. I was wrong.
Now I decide which way to move forward, that would not have problems with the transition to Silverlight 4 and future versions.

Vladimir.

Feb 4, 2010 at 5:19 PM
Edited Feb 4, 2010 at 5:22 PM

About witch garanties I talk.
For me the main thing that using of technologies (in this case, DLR, JScript, IronPyton) did not become a barrier to migration to Next version of Silverlight. 
When I try to make sample Silverlight 4 Betta 2 project whitch use JScript or IronPyton (ver 2.6) in both cases I got error while script execute.
I write about this problem in previous thread

dinov wrote:

Microsoft of course reserves the right to cancel any project at any point in time – look at Flight Simulator, who could have seen that coming?  So is there a guarantee you’ll get bug fixes for the next 10 years?  No.  Is it getting cancelled tomorrow?  Nope, that’s not going to happen either. 

Coordinator
Feb 4, 2010 at 6:21 PM

You might look at IronJS if you want a JavaScript implementation.  It’s still early but it might ultimately serve as a replacement you could use.

From: darrin [mailto:notifications@codeplex.com]
Sent: Thursday, February 04, 2010 6:16 AM
To: Dino Viehland
Subject: Re: Future of IronPython and others languages based on DLR [dlr:82995]

From: darrin

Thank you all for your answers.

I started this thread, that would be determined by the future of project of our company. Development began when the last available version of Managed JScript was released. JScript was chosen as the scripting language, since the syntax of JScript is more familiar to developers. Managed JScript is not Open Source project, so I thought that Microsoft did not drop it. I was wrong.
Now I decide which way to move forward, that would not have problems with the transition to Silverlight 4 and future versions.

Vladimir.

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Feb 4, 2010 at 6:24 PM
The only drawback I currently see with IronJS is that it is currently
dependent on .NET 4.0 (as far as I could tell). I've been pondering
backporting it (if possible) to earlier versions of the .NET
framework, but haven't had a chance.

On Thu, Feb 4, 2010 at 11:22 AM, dinov <notifications@codeplex.com> wrote:
> From: dinov
>
> You might look at IronJS if you want a JavaScript implementation.  It’s
> still early but it might ultimately serve as a replacement you could use.
>
> From: darrin [mailto:[email removed]
> Sent: Thursday, February 04, 2010 6:16 AM
>
> To: Dino Viehland
> Subject: Re: Future of IronPython and others languages based on DLR
> [dlr:82995]
>
> From: darrin
>
> Thank you all for your answers.
>
> I started this thread, that would be determined by the future of project of
> our company. Development began when the last available version of Managed
> JScript was released. JScript was chosen as the scripting language, since
> the syntax of JScript is more familiar to developers. Managed JScript is not
> Open Source project, so I thought that Microsoft did not drop it. I was
> wrong.
> Now I decide which way to move forward, that would not have problems with
> the transition to Silverlight 4 and future versions.
>
> Vladimir.
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com



--
slide-o-blog
http://slide-o-blog.blogspot.com/
Coordinator
Feb 4, 2010 at 6:27 PM

Are you sure you’re using the final version of IronPython 2.6?  There is a breaking change in SL4 where an API that was not security critical has become security critical.  We used that API as part of a call to Array.Sort and so now you can see that exception.  But IronPython 2.6 and 2.0.3 both contain the fix for this.

If you were feeling really adventurous and dedicated to Jscript you could ildasm, fix the IL, and then ilasm the DLR assembly and you’d probably have a working JS build again.  You’d need to pull the new IL from the latest IronPython binaries.  The changed code was in ReflectionCache.MethodBaseCache where we compare the methods, likely you can just replace that entire classes implementation with the new one.

From: darrin [mailto:notifications@codeplex.com]
Sent: Thursday, February 04, 2010 9:19 AM
To: Dino Viehland
Subject: Re: Future of IronPython and others languages based on DLR [dlr:82995]

From: darrin

About witch garanties I talk.
For me the main thing that using of technologies (in this case, DLR, JScript, IronPyton) did not become a barrier to migration to Next version of Silverlight.
When I try to make sample Silverlight 4 Betta 2 project whitch use JScript or IronPyton (ver 2.6) in both cases I got error while script execute.
I write about this problem in previous thread

Vladimir

dinov wrote:

Microsoft of course reserves the right to cancel any project at any point in time – look at Flight Simulator, who could have seen that coming? So is there a guarantee you’ll get bug fixes for the next 10 years? No. Is it getting cancelled tomorrow? Nope, that’s not going to happen either.

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Feb 4, 2010 at 6:37 PM

slide_o_mix: Yes, the current version of IronJS on GitHub is dependent on .NET 4.0, but that is more a proof of concept than a finished implementation. The new/rewritten implementation will be .NET 3.5 compatible and also run on Mono 2.6.