septiembre 29, 2008

Silverlight 2 ya está liberado para desarrolladores

La versión final (release candidate) está disponible para que los desarrolladores puedan probar y ajustar sus aplicaciones antes de que el runtime llegue al público, en unas semans más (no hay fecha oficial todavía).

El detalle más completo proviene, como siempre, del blog de Scott Guthrie, pero los puntos fundamentales que me parece importante destacar son:

  • Otra vez: es sólo para desarrolladores, para estar preparado a tiempo si uno tiene aplicaciones en producción con la Beta 2.
  • Se agregaron algunos controles nuevos, como el esperado ComboBox, un PasswordBox y una ProgressBar.
  • Hay una cantidad importante de cambios que rompen compatibilidad hacia atrás.
  • Se liberó en paralelo Expression Blend 2.0 SP1, que soporta todos estos cambios.
  • Hay runtimes actualizados (para desarrolladores) tanto para Windows (dentro del SDK) como para Mac.
  • También se incluyeron nuevos skins, se mejoraron detalles de rendering para emprolijar la presentación, etc.

Lo más importante del anuncio, por supuesto, es que con esto ya estamos mucho más cerca del release final, lo que significa disponibilidad total y la posibilidad de empezar a desarrollar sabiendo que ya no va a haber cambios mayores.

septiembre 16, 2008

Technight en proceso

image Estamos preparando un Technight sobre lenguajes con el Maestro y Rodo.

Es una especie de actualización de una velada que hicimos con el Maestro allá por el 2005, sobre lenguajes de programación. Recuerdo que esa noche me tocó mostrar C Omega, una versión experimental de C# que tenía consultas integradas al lenguaje, y justo pude contar que ese mismo día, por la mañana, se había anunciado LINQ, el producto final.

Algunos puntos de contacto habrá también con otro Technight que hicimos con Rodo más recientemente sobre el DLR, aunque no entraremos en tantos detalles sobre la plataforma sino sobre lo que se hizo arriba.

Como acabamos de cerrar el abstract para el anuncio, lo comparto con ustedes. El evento será promediando octubre, y ya saldrá publicado en el MSDN Flash y aparecerá en el sitio de MSDN Latam.

Programando en Babel: Esos raros lenguajes nuevos

.NET como máquina virtual permite la implementación de múltiples lenguajes. Originalmente el CLR brindó un excelente soporte para lenguajes estáticos y algunos funcionales, proveyendo un sistema de tipos comunes, un garbage collector y varios mecanismos que facilitaban la implementación de lenguajes interpretados y compilados, capaces de reaprovechar la Base Class Library. El nuevo Dynamic Language Runtime (DLR) extiende este poder a los lenguajes dinámicos y otros más experimentales, e incluso está impactando a nivel de diseño las próximas versiones de la plataforma.

En esta sesión haremos una puesta al día sobre las últimas versiones de lenguajes como F#, Boo, ajBasic, IronPython y varios otros. También charlaremos de características generales del campo de diseño de lenguajes y los objetivos de mantener esta variedad. Finalmente, especularemos sobre el impacto que tiene la problemática del desarrollo de lenguajes sobre el futuro de la plataforma .NET.

septiembre 02, 2008

Javascript - La programación del futuro

image Para los que no lo saben aún, Google está a punto de lanzar hoy browser propio desarrollado casi desde cero: Google Chrome, basado en el motor WebKit que usa Opera, y el proyecto quedará publicado como open source.

Como no podía ser de otra manera, el Maestro se ha hecho eco de la noticia, y leyendo sus comentarios retomo una idea que me viene rondando hace rato:

En poco tiempo el lenguaje de desarrollo principal será Javascript.

Lo mío no es ninguna iluminación; ya lo comentó más extensamente el inefable Steve Yegge, y mucha gente más. Y de hecho no es futurología; ya está sucediendo.

 

¿Cómo un lenguaje famoso por sus limitaciones y complejidades ha llegado tan lejos? Creo que básicamente porque el lenguaje mismo nunca fue el problema, sino cuestiones de contexto. Los culpables principales de la mala de Javascript son los browsers, creo.

 

Problema 1 - Incompatibilidades

Los mayores problemas de escribir código cliente en los browser son las incompatibilidades de sus APIs, que obligan a aplicar soluciones sumamente complejas para tareas triviales.

La solución a este tema son las librerías de más alto nivel que resuelven estos temas por nosotros, brindándonos de paso más funcionalidad lista para usar (y adecuadamente probada), minimizando la cantidad de código necesario por varios niveles de magnitud. El ejemplo más notorio de esta tendencia para mi es jQuery.

 

Problema 2 - Implementaciones

El rendimiento tradicional de Javascript no ha sido -digamos- brillante. Las implementaciones originales estuvieron pensadas para escenarios limitados y no en el uso intensivo que se le da actualmente. La manera en que se representan los objetos en memoria es poco eficiente, y por eso en aplicaciones complejas el desempeño empeora meteóricamente.

Varias soluciones están en camino. Tanto WebKit/Opera, como Mozilla/Firefox e Internet Explorer 8 siguen mejorando las implementaciones del lenguaje, pero más radicalmente, Microsoft está trabajando en su implementación de Managed JScript, que es una implementación basada en el Dynamic Language Runtime, que ejecuta JScript sobre el runtime de .NET (dentro del browser, utilizando Silverlight).

El inminente Chrome de Google utiliza también una máquina virtual llamada V8, que cambia radicalmente el ciclo de ejecución, compilando parte del código al código de la plataforma nativa, y mapeando las estructuras de datos a estructuras reales.

 

Problema 3 - Herramientas

Los entornos de desarrollo más usados para Javascript han sido tradicionalmente editores de texto, desde el espartano Notepad hasta los más profesionales VIM ó Notepad++.

Sin embargo, la explosión de Ajax ha provocado un nuevo acercamiento, y hoy hay IDEs mejores como Aptana, Spket, o el nuevo y mejorado Visual Studio 2008. También, el uso de Annotations en el lenguaje se ha popularizado como una manera de proveer mejor información a las IDEs sobre las API de las librerías y el código, mejorando las posibilidades de las herramientas de brindar feedback permanente.

 

Problema 4 - Lado servidor

Es cierto: este tema no parece tan importante todavía, pero existe, y tiene que ver con la brecha entre el modelo de programación del lado cliente y del lado servidor.

La primer medida para mejorar la situación es el creciente uso de JSON como formato de serialización, enviando datos desde el servidor al browser de manera que éste pueda realizar un Eval() y reproducir una estructura de datos sin necesidad de un parseo más costoso. Incluso Windows Communication Foundation ha incorporado JSON como un formato alternativo de intercambio de mensajes.

Sin embargo, estamos generando esto desde el servidor un tanto antinaturalmente, porque escribimos el código de ese lado en otra cosa (Python, PHP, C#, Ruby, etc). El siguiente paso, con las APIs adecuadas, y un motor de ejecución eficiente como el DLR ó V8, es utilizar Javascript del lado del servidor. En el mundo Java también hay varios proyectos trabajando fuerte en este sentido, como Phobos, Helma o Rhino.

 

Venciendo nuestros prejuicios

Ha llegado la hora. Con el soporte adecuado a nivel de ejecución, herramientas apropiadas y un buen conjunto de librerías, Javascript vuelve a ser un lenguaje que combina elegantes características dinámicas, funcionales y de prototipos. Tiene la sintáxis familiar de la familia C, y todos los desarrolladores web -en mayor o menor medida- hemos pasado por ahí.

¿En qué programaremos nuestras nuevas aplicaciones en dos o tres años más? Mi apuesta está hecha.

septiembre 01, 2008

SDK de Dynamic Silverlight actualizado

dynamicSilvelightJimmy Schementi publicó la tercer iteración del SDK que permite desarrollar aplicaciones Silverlight utilizando IronPython, IronRuby y/o JavaScript manejado ejecutándose dentro del browser.

El SDK incluye todo lo necesario para programar aplicaciones cliente utilizando estos lenguajes, incluyendo Chiron (un web server mínimo que automatiza la construcción de los archivos .XAP que empaquetan una solución Silverlight, facilitando la ejecución durante el desarrollo), y los tres lenguajes.

En todos los casos están disponibles los fuentes, lo que es sumamente interesante aún si uno no es un language freak que se interese por estos temas. En particular, Chiron es un bello ejemplo de código: unos 100 Kb de fuente en C# que implementan lo básico de un servidor web y más.

La versión de IronPython es la 2.0.xxx, aún no liberada, que utiliza el Dynamic Language Runtime (la última versión estable es la 1.1.2, pero no tiene el runtime factorizado y no está soportada en Silverlight), e incluye los módulos estándar.

El build de IronRuby es uno de los últimos y también incluye las librerías, al igual que sucede con JScript.

Recordemos que todo esto -aunque muy avanzado-, sigue siendo preliminar porque Silverlight 2.0 (la versión que incluye el runtime de .NET y soporte para lenguajes estáticos y dinámicos) está todavía en Beta 2.

Es de esperar que las versiones finales de los lenguajes y el SDK confluyan con el lanzamiento de la versión final de Silverlight 2.