Lenguajes Dinámicos – IronPython y ASP.NET y los primeros pininos con IronRuby

Tal como el CLR y especialmente el CLS sirven de base para los lenguajes estáticos como C#, VB.NET, J#, Delphi.NET y otros menos exitosos que han surgido (no que Delphi .NET hay tenido éxito). Microsoft está trabajando sobre esta nueva cosa que llaman el DLR (Dynamic Language Runtime) que les va a servir de base para hostear lenguajes dinámicos de una manera eficiente permitiéndoles hacer llamadas a APIs de .NET, algunas de las implementaciones son IronPython, IronRuby, JavaScript y Dynamic VB. En este post daré una muy breve introducción a IronRuby y los redirigiré a un buen ejemplo de Scott Guthrie y veremos un poco más a fondo como IronPython, que ya es un poco más maduro que IronRuby, se integra con ASP.NET de una forma bastante ingeniosa y finalmente veremos algunas de las ventajas.

Como todos deberían de saber, los lenguajes dinámicos, especialmente Ruby usado en conjunto con Ruby on Rails han estado ganando mucha popularidad y tienen ciertas ventajas en comparación con los lenguajes estáticos. Por lo poco que he usado Rails tengo que aceptar que se puede ser muy productivo, aunque hay muchas cosas que extraño como Intellisense, Visual Studio, la depuración, muchas herramientas a las que estoy acostumbrado (Team System, Unit Testing, RhinoMock, etc.), pero especialmente el .NET Framework, por lo que la idea de lenguajes dinámicos que puedan interoperar con este último suena muy atractiva. Por otro lado, según benchmarks que han hecho (les debo la referencia, simplemente lo leí en algún lado y lo escuche en algunos audios) tanto las implementaciones de Microsoft de Ruby, Python y JavaScript para el CLR son muy eficientes gracias a que se convierten en código compilado al vuelo en lugar de interpretado.

Scott Guthrie recientemente escribió una introducción a IronRuby que consiste en unos simples ejemplos de consola y luego una demo de cómo usar WPF con IronRuby. Les dejo el link al ejemplo y al código fuente de IronRuby que está en la página de John Lam donde explica un poco más del proyecto, también pueden escuchar su John Lam on the DLR de DotNetRocks o John Lam on Iron Ruby en Hanselminutes. Algo interesante es que se liberará usando la Microsoft Permissive License y están invitando a gente externa a Microsoft en participar en el proyecto. Hay muchas cosas que aún no funcionan bien, pero nos podemos dar una idea de lo que viene.

IronPython ya se integra con ASP.NET podemos ver más detalle en este WhitePaper o en el audio Language Extensibility - Iron Python de DotNetRocks donde explican lo mismo. En resumen, en lugar de usar el CodeDOM para hacer el merge una página ASP.NET con la clase parcial del CodeBehind o CodeFile, utilizan el modelo de no compilación, similar a como hacen los sitios de Sharepoint. Este modelo siempre ha estado disponible y puede ser algo útil por ejemplo en páginas que no requieren de código y todo lo que usan son controles que saben cómo hacer el trabajo. Todo el truco para integrar con lenguajes dinámicos (actualmente sólo IronPython and managed JScript) es que usan uno de los puntos de extensión para cambiar el parser de ASP.NET y cambian los codesnippets (<% ... %>, <%= ... %>, <%# ... %>) por un control que tiene una propiedad con el código, por lo que sigue siendo básicamente sólo un control y la página se puede usar en el modelo de no compilation. Las páginas también podrían tener "Codebehind" o archivos de script ligados a estás aunque a diferencia de páginas con código estático, este no forma parte de la clase Page, más bien es simplemente un modulo que tienen disponible para utilizar sus métodos o propiedades directamente, de igual forma funciona con código en línea como <script runat="server"> someVar=5 </script>. Cada página tiene su propia instancia del modulo, por lo que está variable será distinta en las diferentes páginas, controles, etc. Sin embargo dado que es una variable global será similar a una variable estática en C#. Vale la pena destacar, que aunque se use el No-Compilation, desde todo el ciclo de parsing-ejecución de la página, realmente el código de IronPython se termina compilando al vuelo por el motor de lenguajes dinámicos teniendo las ventajas de performance.

Ahora que entendemos un poco de la teoría de cómo funciona el nuevo modelo, veamos algunas de las ventajas. Las expresiones de DataBing como <%# Eval("City") %> se pueden sustituir por expresiones más simples como <%# City %>, que aunque no existe en tiempo de parse, se puede evaluar en tiempo de ejecución. IronPython usa un mecanismo de inyección que nos permite hacer este tipo de cosas raras, como por ejemplo en lugar de decir String myValue = Request.QueryString["MyValue"]; podríamos simplemente decir myVar = Request.MyValue. La secuencia sería la siguiente, si el objeto no tiene ninguna propiedad llamada MyValue, intercepta la llamada el inyector e internamente hace lo mismo que haríamos en C#, permitiéndonos tener una sintaxis más clara. Lo mismo se hace por ejemplo al obtener controles, con C# haríamos algo como SomeControl.FindControl("SomeChildControl") y ahora en injector nos permite usar directamente código como SomeControl.SomeChildControl sin necesidad obviamente de hacer un cast. Podríamos hacer algo como nombre = FormView1.NombreTextBox.Text.

Pueden ver un Quickstart y descargar los ASP.NET Futures de July para hacer algunas pruebas. Ya que lo tengan pueden usar el Personal Starter Kit Python para aprender un poco. Para los que ya saben Python puede ser muy fácil una vez entendido todo el modelo. Yo me esperare mejor a ver las implementaciones con IronRuby.