Ayer hubo un evento de lanzamiento de Visual Studio 2013, donde Microsoft conato una serie de novedades. Algunas eran sabidas, dos en particular me llamaron la atención, porque me parece que son movimientos en la dirección correcta.
Finalmente se mostró el primer preview de la versión online de Visual Studio, que al parecer sólo se puede ver en videos por ahora, pero suena interesante. A pesar de estar bastante pegada a TFS online, una plataforma que no me resulta especialmente atractiva, mantiene y expande una actitud más abierta, con fuerte integración con Git, como se puede ver en el video que dejo debajo. Por otro lado, como verán, Node mantiene una presencia muy fuerte, con gran cantidad de ejemplos. La idea de que este entorno sea gratuito para grupos reducidos es importante.
Leí un par de notas periodísticas que mencionan esta iniciativa como una competencia directa de Microsoft a GitHub, que realmente me hicieron reír. Es cierto que algunos desarrolladores muy establecidos en el ecosistema Microsoft pueden preferir moverse en algún momento, pero no veo ninguna posibilidad de que algo de esto se plantee como una alternativa masiva. Al contrario, veo que son plataformas que pueden complementarse, y aunque no tengo chance de probarlo todavía, intuyo por las demos que tranquilamente se podría trabajar con esta IDE online desde un repositorio de GitHub. No veo ninguna dificultad técnica, y confío que el espíritu de apertura que intentan mantener desde este grupo de Microsoft no genere una barrera artificial.
Queda un video breve (~ 5 min) donde se muestra un proyecto Node, y cómo se utiliza el entorno, altamente integrado con TypeScript, que es otra estrategia interesante, sobre todo por lo poco intrusiva:
El otro gran anuncio es una asociación más directa con la gente de Xamarin, la empresa formada por los iniciadores del proyecto Mono, y todavía uno de los mayores grupos contribuyendo con él, que se dedica a permitir el desarrollo de aplicaciones nativas (no híbridas) en C# para iOS, Android, Windows Phone, OS X y otras plataformas (por extensión).
Lo interesante de esta asociación es que más allá de temas comerciales, tiene puntos técnicos muy importantes, logrando abrir más las puertas del ecosistema Microsoft / .NET hacia el exterior. Por ejemplo, las Portable Class Libraries (PCL) de .NET son ahora realmente abiertas y soportan el movimiento de librerías entre cualquier plataforma, facilitando muchísimo el intercambio también a nivel NuGet (el mecanismo de manejo de dependencias abierto del mundo .NET).
En total, esta noticia parece más de índole comercial, pero para mi el acercamiento al equipo de Xamarin y el reconocimiento del valor de llegar a estas plataformas fuera de su control son un blanqueo y una buena actitud que espero seguir viendo desde Microsoft hacia afuera.
Un grupo conformado por algunos de los sospechosos de siempre en el ambiente .NET han formado esta organización sin fines de lucro para evangelizar y apoyar activamente el desarrollo de proyectos y plataforma de código abierto alrededor de .NET.
Hay algunos ex-Microsoft como Phil Haack (actualmente en GitHub), Joseph Hill, cofundador de Xamarin con Miguel de Icaza, Dale Ragan, cofundador de Moncaí (una Plataforma como Servicio basada en Mono), e incluso un empleado activo (hiper-activo, en realidad) de Microsoft como Scott Hanselman.
Entre otras cosas, esta organización es actualmente la responsable de la conferencia MonoSpace 2012, que se realizará del 17al 19 de octubre en el Microsoft NERD Center (no, el nombre no es chiste) de Cambridge, Massachusetts. Los interesados en la conferencia puede acceder a todas las presentaciones de la edición del año pasado en InfoQ.
No hay muchas más noticias por ahora, pero parece un movimiento interesante.
Este post debería haber salido hace bastante tiempo atrás, durante el lapso en que este blog estuvo silencioso, pero -nobleza obliga- hay gente conocida que trabajó mucho por esto y vale la pena comunicarlo para los que todavía no estaban al tanto.
El equipo de ASP.NET MVC avanzó un paso muy grande en su impulso hacia el código abierto a fin de marzo pasado al publicar el stack completo de MVC 4, incluyendo Web API, Web Pages (o Razor, el motor de rendering de vistas) con contribuciones externas, bajo licencia Apache 2.0.
Como detalle interesante, el código del stack completo está alojado en GIT dentro de CodePlex (que hace tiempo soporta GIT y Mercurial además de TFS y SVN). Esto implica que los curiosos sólo necesitan hacer un:
Desde el anuncio, Microsoft avanzó hasta la publicación en junio de las "release candidates" de MVC 4 (incluyendo ya un montón de contribuciones de la comunidad) y Visual Studio 2012. MVC 4 también incluye otros paquetes abiertos como jQuery, jQuery Mobile, jQuery UI, Modernizr, Knockout y JSON.NET.
Otro detalle interesante es que MVC no está atado a Visual Studio ni a .NET, y también corre en Mono. Casualmente, Miguel de Icaza (líder del proyecto Mono) fue el primero en contribuir con un pull request.
Dejo para el final un video (en 6 partes, ~80 minutos, en inglés) de Scott Guthrie presentando MVC 4. El video tiene un tiempo, pero es de lo mejor que encontré, presentado por la persona que está directamente detrás del proyecto, y uno de los mayores impulsores del código abierto dentro de Microsoft. No por casualidad, ahora que Scott está a cargo de la experiencia de desarrollo de Azure, todos los SDK y herramientas son también abiertas.
Heroku es un servicio PaaS (Plataforma como Servicio), que permite publicar en la nube aplicaciones Ruby (el lenguaje soportado originalmente), Node.js, Scala, Java y Python.
La plataforma es fabulosa porque tiene un modelo de escala muy interesante, y es muy sencillo montar aplicaciones de manera gratuita por bastante tiempo, hasta que el volumen de tráfico y consumo de recursos requiere que se pase a un plan pago (lo que en muchos casos debería suceder cuando la aplicación ya está generando dinero).
Por otro lado, Heroku es una de la plataformas en su tipo con mayor simpleza para el despliegue y mantenimiento de las aplicaciones. Fuertemente basada en los flujos de trabajo de GIT, el sistema distribuido de control de versiones (creado por Linus Torvalds), para las plataformas soportadas directamente, desplegar una aplicación es tan simple como ejecutar desde la línea de comandos, parados sobre nuestro repositorio de GIT local:
git push heroku master
Y listo. Heroku se encarga de resolver todas las dependencias de acuerdo a las convenciones de cada plataforma (bundle en Ruby, NPM en Node, etc), lo que usualmente es muy rapido, y hace que nuestra aplicación esté disponible en segundos.
Bueno, esto ya debe ser conocido por la mayoría de los lectores de este blog. La novedad es que Ben Hall, un colega desarrollador que trabaja regularmente en ASP.NET y Rails, encontró la manera de desplegar en Heroku una aplicación basada en Mono (la implementación abierta y gratuita de .NET).
La aplicación de prueba está escrita en C# y basada en el framework Nancy (basado en Sinatra, un framework web minimalista para Ruby; Nancy es el nombre de la hija de Frank Sinatra). Como Ben explica en este post, este mecanismo no está soportado en lo más mínimo por Heroku, pero abre el camino para que eventualmente sea soportado (nótese que todos los lenguajes soportados además de Ruby fueron agregados en los últimos seis meses, aproximadamente).
Aunque el proceso es bastante experimental (requiere desplegar unas cuantas piezas de infraestructura sobre el stack Cedar de Heroku, que es el más nuevo de los sabores, y provee proceso sobre Ubuntu 10.04, y sobre el que corren todos los nuevos lenguajes.
La prueba final de que esto puede pasar de ser un experimento a algo más es que Chris Kemp, del equipo de Soluciones Técnicas de Salesforce.com (la compañía dueña de Heroku) grabó este video (en inglés) en el que muestra cómo poner en práctica la receta de Ben. Disfrutenlo, y esperemos que dentro de un tiempo podamos tener soporte más directo para Mono en Heroku.
Se va terminando el año 2011 y mirando hacia atrás desde la perspectiva de la comunidad .NET somos varios los que vemos que este año fue sumamente importante para el código abierto en ese entorno. Y no estoy hablando solamente de Microsoft, ya que .NET ya tiene entidad independiente de su creador original.
Para los que tienen ganas de leer posts más largos y en inglés, recomiendo los de Phil Haack (hasta hace poco líder del ASP.NET MVC en Microsoft, ahora trabajando para GitHub) y Miguel de Icaza (el incansable líder del proyecto Mono).
Este post es un resumen breve del contenido que ellos exponen, con algunas apreciaciones personales.
El modelo Open Source fue algo que Microsoft, con su tradición de secretos y licenciamiento complejo, tardó muchísimo en incorporar. Y más complejo aún el modelo de Free Software, que implica tanto apertura como gratuidad de los productos. Sin embargo, desde hace años, con pioneros como IronPython, el DLR, y más tarde ASP.NET MVC, varios productos de la plataforma de desarrollo empezaron a producirse bajo esta premisa. Un punto culminante de esta iniciativa fue en 2008, cuando Microsoft anunció que comenzaba a incluir jQuery en Visual Studio, colaborando con el proyecto (de manera abierta, como cualquier otro) e incluso brindando soporte sobre el mismo.
Al entender la importancia del movimiento, Microsoft finalmente generó una Fundación llamada OuterCurve (originalmente se llamaba CodePlex, pero usar el mismo nombre que su sitio de alojamiento de código resultaba muy confuso), que como la Fundación Apache, permite resguardar los derechos del código y de los autores en un ambiente controlado. Muchos proyectos hoy existen bajo OuterCurve, aunque hay muchos también directamente en Apache.
Finalmente, este año Microsoft avanzó más en ese sentido, mejorando notablemente las condiciones de búsqueda e integración de código abierto propio o de terceros, a través de NuGet, el administrador de versiones para .NET, inspirado en Ruby Gems y similares. NuGet se integra en Visual Studio o puede usarse en la línea de comando, y permite buscar en un catálogo muy abundante actualmente de componentes abiertos, instalarlos en nuestros proyectos, incluyendo todas sus dependencias, e incluso automatizar tareas relativas a su instalación y uso, como declararlos en configuraciones, generar código u otros artefactos desde la consola, etc. NuGet también facilita mantener actualizadas, si es necesario, todas las versiones de estos paquetes.
Más allá de la reagrupación, que no redujo en lo más mínimo el impulso del proyecto Mono, a pesar de que el equipo de Xamarin se concentró en poner en el mercado MonoTouch y Mono for Android (productos comerciales que les permiten seguir sobreviviendo). Mientras tanto, el equipo de Mono (que excede también a Xamarin, como todo gran proyecto abierto) entregó este año una avalancha de tecnologías (más allá de varias versiones del runtime mismo de Mono y de MonoDevelop, su IDE), incluyendo:
.NET en el navegador (al menos en Chrome) a través de Mono corriendo en el Native Client de Google. De hecho, Google mostró Mono en Chrome en un evento reciente, del que dejo el video al final de este post. Aunque el año pasado ya se podía programar en mono y utilizar el compilador estático para ejecutar código dentro de Chrome, este año ya se puede ejecutar el compilador a demanda (JIT) de Mono.
MonoMac es una extensión de Mono para programar aplicaciones para Mac OS X en .NET, incluyendo el soporte para Cocoa y todo el entorno del sistema operativo. Se programa utilizando MonoDevelop y algunas herramientas nativas como los diseñadores de XCode.
MonoGame (ya comentado antes en este blog) es un port del entorno de desarrollo de juegos XNA de Microsoft, pero abierto y con mayor alcance en plataformas.
Sony PlayStation Suite es un framework de Sony para desarrollar juegos en diferentes dispositivos de su línea, completamente basado en Mono.
Phalanger es un compilador de PHP, actualmente basado en Mono, utilizando el DLR, que además de ser el motor PHP de mayor rendimiento, permite extender ejecutar cualquier aplicación PHP y extenderla con librerías o aplicaciones .NET.
CXXI es una tecnología puente entre C# y C++ que permite ejecutar código de una a otra plataforma, pero también heredar clases entre ellas, sobre-escribiendo métodos o no, o llamando a la clase base, todo de manera muchísimo más sencilla, segura y multi-plataforma que utilizando COM.
Y hay bastante más (ver el post de Miguel para el detalle completo), pero como detalle final, Miguel descubrió que Microsoft mismo utilizó Mono para producir el juego Kinectimals para iOS. ¡Toda una ironía!
Dejo el video (en inglés) del evento de Google Client para que lo disfruten:
Como todos saben, soy bastante fanático de Mono, la implementación de código libre y abierto de .NET, liderada por Miguel de Icaza.
El año pasado se inició un proyecto llamado inicialmente XNATouch, cuyo objetivo era permitir portar juegos desarrollados en XNA (la plataforma para desarrollo de juegos en XBOX y Windows Phone) a iOS (iPhone, iPod y iPad). El proyecto avanzó bastante, cambió de nombre a MonoGame, y el mes pasado llegó a su versión 2.0, extendiendo el alcance de iOS a Android, Linux, Windows y Mac OS, y de paso, mudándose a GitHub.
El proyecto es muy interesante porque brinda un mecanismo sólido de desarrollo de juegos para múltiples plataformas, algo que es cada vez más requerido por quienes producen para esta industria, sobre todo en los ambientes móviles.
Como ejemplo, este es el código de arranque para ejecutar un juego desarrollado en XNA en iOS (utilizando MonoTouch):
using MonoTouch.Foundation;
using MonoTouch.UIKit;
using Microsoft.Xna.Framework;
namespace MonoGame.Samples.Storage
{
[Register ("AppDelegate")]
class Program : UIApplicationDelegate
{
private Game1 game;
public override void FinishedLaunching (UIApplication app)
{
// Fun begins..
game = new Game1();
game.Run();
}
static void Main (string [] args)
{
UIApplication.Main (args,null,"AppDelegate");
}
}
}
Por ahora el framework soporta solamente juegos 2D, y el API de 3D es el foco principal de trabajo para la versión 3.0. Si está disponible el stack de networking suficiente para permitir jugadores simultáneos dentro de un mismo segmento de red, sin importar la plataforma en que estén ejecutando el juego.
Para quienes quieran ver el proceso en más detalle, recomiendo esta serie de 4 artículos de Alfredo Machin, en las que describe el proceso de migración de un juego XNA a Mac OS (utilizando MonoMac): Parte 1, Parte 2, Parte 3, Parte 4.
El equipo del proyecto Mono, ahora formal y legalmente a cargo del equipo original reagrupado en Xamarin tras su salida de Novell, retoma el ritmo de entregas progresivas con su versión 2.10.3 que a pesar de ser una entrega “de mantenimiento” sorprende con estadísticas como:
Mientras tanto, para espíritus exploradores, accediendo al código fuente más actual desde el repositorio de Mono en GitHub, se puede comenzar a probar el soporte para C# 5.0, al menos sobre las características definidas y publicadas hasta ahora por Microsoft.
Esta semana Novell / SUSE anunció que firmó un amplio acuerdo de colaboración con Xamarin, la compañía formada por el equipo que trabajaba para ellos en el desarrollo de estos productos, liderada técnicamente por el infatigable Miguel de Icaza y comercialmente por su socio de años, Nat Friedman.
El acuerdo incluye transferencia a perpetuidad a Xamarin de todos los derechos de propiedad intelectual de todos los productos de la familia Mono (incluyendo MonoTouch, Mono for Android and Mono for Visual Studio) y el control de todas las propiedades relativas al proyecto Mono, como MonoDevelop y la organización Mono en GitHub, y a cambio se compromete a brindar soporte a todos los clientes de SUSE utilizando la plataforma, lo que es un factor importante para grandes cuentas de Novell utilizando las ediciones Enterprise de Mono.
Básicamente, desde mi punto de vista, es una acuerdo de colaboración basado en el hecho de que Novell no puede hacer mucho con esos productos sin el equipo detrás, pero necesita seguir dando respaldo a muchos clientes que los están utilizando. Como menciona el gerente general de SUSE en el anuncio oficial, con este acuerdo ganan las tres partes: Novell, Xamarin y los clientes de ambos.
Inmediatamente después de sellado el trato, Xamarin puso nuevamente disponibles los productos en su tienda en línea, y en el anuncio de Miguel se entiende que gran parte del esfuerzo que Xamarin inició para construir estos productos desde cero (mientras negociaban este acuerdo) va a aplicarse directamente como correcciones e implementación de nuevas características en los productos existentes.
La noticia es muy buena también para la comunidad de código abierto, ya que aunque estos productos que permiten programar en C# en plataformas móviles son pagos, son también la fuente de financiamiento que la empresa necesita para continuar liderando el desarrollo del proyecto Mono, MonoDevelop y los demás componentes abiertos y gratuitos, que nunca se detuvieron.
Prueba de que todos estos cambios nunca afectaron demasiado a la comunidad es que este sábado 23, y hasta el lunes 25 se llevará a cabo la conferencia MonoSpace 2011, dedicada a la plataforma abierta, y alojada en el NERD Center de Microsoft en Boston. La conferencia se empezó a organizar antes de que el equipo de Mono fuera despedido de Novell, y la organización nunca se detuvo a pesar de todas las idas y vueltas que felizmente han concluido en este acuerdo que deja en completo control al equipo original.
(gracias a José Romaniello por descubrirme este interesantísimo lenguaje)
Cobra es un lenguaje multi-plataforma y multi-paradigma que combina una cantidad de características sumamente interesantes.
Es obra de Charles Esterbrook, y su autor describe sus principios de diseño de la siguiente manera:
Programación rápida y expresiva
Rápida ejecución
Tipado estático y dinámico
Calidad soportada a nivel del lenguaje
Por supuesto que suena ambicioso y vendedor, pero en principio, es bastante realista. Veamos cómo se soporta cada cosa:
Programación rápida y expresiva
Cobra tiene una sintaxis basada en Python (sobre todo) y Ruby, lo que lo hace mucho más legible que los lenguajes "con llaves y punto y coma". Entre otras cosas, en Cobra los bloques se determinan por indentación, las listas y diccionarios se pueden declarar como literales, hay comandos como print y assert de uso sencillo y poderoso, la manera de iterar y dividir listas es simple, y mucho más.
Un ejemplo rápido de la sintaxis, con la definición de una clase:
class Person
"""
Declaración de una clase. Este comentario documenta la clase misma
"""
var _name as String # Declara variables de instancia (no estáticas)
var _age as int
cue init(name as String, age as int) # Inicializador (constructor)
base.init
_name = name
_age = age
def sayHello # Métodos
# Los corchetes interpolan valores en las strings
print 'Hello. My name is [_name] and I am [_age].'
def divide(i as int, j as int) as int
""" Este comentario documenta este método """
assert j > 0 # Si el divisor
return i / j
Rápida ejecución
Esto es logrado a través del uso de tipos estáticos con inferencia permanente, sin perder las capacidades dinámicas para los casos necesarios.
La implementación actual de Cobra utiliza la Infraestructura Comun de Lenguajes (CLI) de .NET/Mono, por lo que el compilador genera código intermedio (IL) que a su vez es es llevado a código nativo por el motor de ejecución de .NET/Mono como en otros lenguajes.
Tipado estático y dinámico
La mayor parte de la resolución es estática y en tiempo de compilación, mientras que siempre que haga falta puede utilizarse resolución dinámica en tiempo de ejecución, basada en Reflection de .NET y apoyándose en técnicas específicas de optimización.
Veamos un ejemplo sencillo de una misma función declarada estáticamente:
def add(a as decimal, b as decimal) as decimal
return a + b
... o dinámicamente:
def add(a, b) as dynamic
return a + b
En la práctica, no son la misma función, ya que la primera opera solamente con números decimales, y la segunda con cualquier tipo que soporte la operación suma.
Obviamente la primer función es más rápida, ya que se verifica y compila, y no requiere más recursos que los operandos de un largo conocido (decimal), mientras que la segunda, al resolverse dinámicamente, es verificada en tiempo de ejecución y requieres más recursos para la conversión de parámetros, etc.
Por otro lado, contar con ambas variantes es lo ideal, ya que podemos aprovechar el contrato estricto de los tipos estáticos para gran parte de la aplicación, pero con la flexibilidad de los dinámicos para las porciones que son más variables, o para facilitar el prototipado.
Nótese que el soporte a tipos dinámicos de Cobra, comparado con el de C# o VB (a partir de .NET 4), es sintácticamente más sencillo, mucho más integrado a nivel del lenguaje.
Calidad soportada a nivel del lenguaje
Cobra soporta contratos de código (algo proveniente de Eiffel que .NET 4 soporta parcialmente), pruebas unitarias, comentarios para documentación y verificación de valores nulos en tiempo de compilación, todo como parte de su sintaxis.
Veamos como las pruebas unitarias quedan embebidas directamente como parte de un método:
class Utils
shared
def countChars(s as String, c as char) as int
"""
Returns the number of instances of c in s.
"""
test
assert Utils.countChars('', c'x') == 0
assert Utils.countChars('x', c'x') == 1
assert Utils.countChars('X', c'x') == 0 # case sensitive
assert Utils.countChars(' ! ! ', c'!') == 2
body
count = 0
for ch in s
if c == ch
count += 1
return count
Las aserciones, además, pueden usarse en cualquier parte del código, y arrojan una excepción con información útil para depuración si no se cumplen (no son un IF).
Los contratos embebidos en el código permiten especificar pre y post-condiciones a los métodos, garantizando la consistencia antes de entrar y después de retornar el valor final. Por ejemplo:
class Customer
var _contacts as List<of Contact>
get contacts from var
def addContact(contact as Contact)
require # Arroja excepción si algo no se cumple ANTES de entrar
contact not in .contacts
contact.name
contact.customer is nil
ensure # Arroja excepción si algo no se cumple DESPUES de salir
contact.customer == this
.contacts.count = old .contacts.count + 1
body
contact.customer = this
_contacts.add(contact)
Y otra característica muy buena de seguridad es que los parámetros o tipos que pueden recibir nil (llamado como en Smalltalk o LISP), son los que se declaran como tales, agregando al sufijo "?" al tipo, como en:
def bar(s as String?)
if s # Es igual que preguntar "if s is not nil"
print Utils.countChars(s, c'x')
Cobra está escrito en Cobra
Una característica más que quiero remarcar es que este lenguaje está escrito sobre si mismo. Por supuesto hay una parte del compilador escrita para la plataforma nativa (C# en este caso), pero el resto está escrito en Cobra mismo, lo que hace que el lenguaje tenga un nivel de depuración y prueba mayor que otros que se construyen generalmente sobre lenguajes de más bajo nivel. Esto está sucediendo en otros lenguajes a posteriori, como en el caso de PyPy o Rubinius, pero en Cobra fue un principio de diseño.
Personalmente me parece uno de los lenguajes "experimentales" más interesantes y completos que he visto en los últimos tiempos, en parte porque se apoya en una plataforma que ya ofrece muchos servicios, y en parte por algunas de sus características maduras que y las herramientas con que ya cuenta (compilador, ejecutor de pruebas unitarias, generador de documentación, coloreador de sintaxis, etc).
Y también cuenta con soporte parcial en algunas IDEs y editores:
Visual Cobra es un complemento para Visual Studio que reconoce y colorea la sintaxis.
Naja es una IDE completa escrita en Cobra que ademas del coloreo de sintaxis tiene soporte para lista de tareas basada en comentarios, soporte para proyectos y un diseñador de formularios que genera código Cobra.
Y si uno prefiere un editor de texto hay muchos para los cuales hay complementos para soportar la sintaxis, incluyendo gedit, Notepad++, UltraEdit, Vim y TextMate (el que estoy usando yo), y mucho más para elegir según la plataforma que cada uno usa. Y para cualquier otro caso existe un detalle de las palabras clave y modificadores, de manera que en cualquier editor se puede partir del soporte para Python y cambiar estas listas.
Finalmente, dejo este video de la presentación de Esterbrook en el Lang .NET Symposium 2008. Aunque la implementación del lenguaje maduró bastante desde entonces, muchos de los principios siguen igual.
Uno de los principios de diseño del framework .NET, o más específicamente del CLI (Common Language Infrastructure) es, como su nombre lo indica, permitir implementar fácilmente una variedad importante de lenguajes.
El CLI es una pieza estandarizada ante ECMA como un estándar abierto, y es lo que ha permitido la creación de implementaciones abiertas de .NET como Rotor y Mono.
Pero también ha permitido la implementación de muchos lenguages (más allá de Microsoft) que comparten todo el ecosistema de herramientas y bibliotecas disponibles.
Nemerle es uno de estos casos. Desarrollado en la Universidad de Wroclaw, Polonia, se trata de un lenguaje de tipos estáticos, casi un superset de C#, que soporta estilos de programación funcional y orientada a objetos, metaprogramación, lenguajes específicos de dominio y mucho más. Al estar basado en el CLI genéricamente, funciona en .NET y en Mono por igual.
Siendo un superset, es posible compilar (con un par de toques en el archivo .csproj) fuentes C# en Nemerle.
Dos de las características más distintivas de Nemerle son la inferencia de tipos y el uso de macros.
Veamos algunos ejemplos de código, con inferencia de tipos:
def d = Dictionary ();
d.Add ("Code and Beyond", 42);
foreach (s in args) {
...
}
Notese que no hace falta inicializar los tipos del diccionario, que son declarados y chequeados a partir del primer uso.
En el caso de las macros, pueden escribirse cosas como:
ExecuteReaderLoop ("SELECT nombre, apellido FROM personas WHERE nombre = $miNombre", dbcon,
{
System.Console.WriteLine ("Persona: {0} {1}", nombre, apellido)
});
que enmascaran la creación del SqlCommand y el SqlReader, la clásica iteración y la obtención de las strings para los dos campos leídos, pero es importante ver que es mucho más que una función de una biblioteca, ya que en este caso se está interpretando la string conteniendo la sentencia SQL y generando el código chequeado correspondiente.
Nemerle también tiene interpolación de strings más eficiente que en C#, ya que se ejecuta en tiempo de compilación, como en:
$"Me llamo $Nombre y tengo $Edad años."
donde las variables reemplazadas son chequeadas por el compilador, a diferencia de utilizar String.Format, donde se realizan en tiempo de ejecución.
Es muy interesante además la sencillez para definir Macros, que no tienen nada que ver con las de C, y son descendientes directas de las macros de LISP. Veamos este caso que define un bucle hacia atrás:
A fines del año pasado comentaba en este blog la venta de Novell a Attachmate, una compañia de servicios de infraestructura.
Una preocupación desde ese momento, aunque al principio no parecía pasar nada, es qué valor iba a darle el nuevo dueño al proyecto Mono (una implementación de código abierto de .NET), liderado por Miguel de Icaza.
Las cosas empeoraron recientemente, y el 2 de mayo comenzaron los despidos de los equipo de EEUU y Candá, seguidos en la semana por el resto en Europa, Brasil y Japón.
Lejos de romper en llanto, el equipo original de Mono, con Miguel a la cabeza, pronto avanzó con un viejo plan que ya había discutido anteriormente y fundaron Xamarin, una companía con la que piensan mantener el servicio de soporte de Mono y el resto de los proyectos abiertos, y generar dos nuevos proyectos similares a Mono for Android y MonoTouch (para iOS). Al igual que los productos que generaron en Novell, éstos últimos serán productos pagos, con los que esperan mantener al equipo funcionando.
Conociendo la calidad y capacidad de producción del equipo, estoy seguro que pronto tendremos novedades al respeto. Miguel estima que en 3 meses pueden tener la versión preliminar para iOS, y en 4 la de Android, y seguramente en ambos casos, al empezar de cero, incorporarán mejoras y aprendizajes por sobre los productos que quedaron en Novell.
Vale recordar que Mono en si y sus otros derivados como Moonlight, MonoMac y MonoDevelop son gratuitos y de código abierto, por lo que no hay riesgos al respecto.
Mientras tanto, la conferencia Monospace sigue programada para el 23 al 25 de julio en Boston, Massachussets, EEUU, en el NERD (New England Research & Development) Center de Microsoft en esa ciudad.
Desde este humilde blog aprovecho para expresar mi admiración y apoyo a Miguel y su increíble equipo en esta nueva etapa, y quedo a la espera de las novedades que seguramente producirán a mansalva, como siempre.
Aunque suene raro, Manos de Mono es el nombre de un framework liviano para desarrollo web, soportado por Mono (la implementación abierta de .NET) e inspirado en Tornado, Sinatra, Node.js y otros mecanismos web recientes.
Creado por Jackson Harper, miembro del equipo de Mono en Novell, este framework intenta simplificar mucho el desarrollo web, evitando abstracciones y herramientas. Jackson usa como inspiración esta elegante frase de Alan Kay (inventor de Smalltalk, entre otras cosas):
"Las cosas simples deben ser simples. Las cosas complejas deben ser posibles."
Manos está concebido para ser simple de usar, fácil de probar y brindar altísimo rendimiento, sin necesidad de utilizar un servidor web (ni Apacha, ni IIS). Las aplicaciones desarrolladas con Manos incluyen el servidor web como parte del paquete, facilitando también la instalación y actualizaciones, y eliminando toda configuración.
Algunas de las características más interesantes de Manos son:
El servidor es muy escalable y no-bloqueante, es decir que no usa threads separados para cada petición, sino un loop de eventos, como hace Node.js (mas información sobre éste último en este post anterior).
Un sistema de cañerías (pipes) HTTP que facilita tratar cualquier petición o respuesta antes o después de que el framework los enrute.
El enrutamiento puede realizarse por convención, propiedades o métodos HTTP. Todas las rutas pueden definirse con expresiones del estilo "/Articulo/{titulo}/{pagina}".
Al generar un nuevo proyecto, Manos produce una serie de archivos básicos basados en el HTML5 Boilerplate (cubierto en este otro post), que después se personaliza por medio de un motor de plantillas muy rápido. Las vistas pueden generarse con cualquier editor y son casi HTML puro, pero son compiladas en tiempo de ejecución para maximizar el rendimiento.
La interfaz principal de Manos es una línea de comandos que permite crear, construir o iniciar las aplicaciones sin necesidad de ninguna IDE.
El diseño es totalmente modular, permitiendo extender Manos fácilmente, lo que puede facilitar que el ecosistema crezca con contribuciones de la comunidad.
Para crear una aplicación Monigote (por ejemplo), basta abrir una consola y escribir:
manos --init Monigote
y esto crea una carpeta Monigote con los archivos Monigote.cs, StaticContentModule.cs y una subcarpeta para las hojas de estilo y librerías Javascript (incluye jQuery, Modernizr, y otras). Los primeros archivos son programs C#, como se habrán dado cuenta. El primero es el punto de entrada de la aplicación, y el segundo se encarga de servir el contenido estático desde la sub-carpeta creada: scripts, imagenes, estilos, etc.
Dentro de Monigote.cs podemos incluir algo tan sencillo como:
Get ("/", ctx => ctx.Response.End ("¡Hola, Monigotes amigos!"));
Y esta acción procesa directamente la ruta raíz ("/"), respondiendo con un saludo.
Por supuesto que hay mucho más, pero este es el estilo de desarrollo en general. Antes de ejecutar la aplicación debemos construirla con el comando:
manos --build
Y para ejecutarla simplemente ejecutamos:
manos --server
Y la aplicación inicia, accesible en el localhost, en el puerto 8080 para pruebas.
Por si alguno de los lectores de este blog aún no lo sabe, Mono es la implementación abierta de .NET para Unix, Mac OS X y Windows.
El increíble equipo de Mono nunca se detiene, siempre acompañado por su líder Miguel de Icaza.
La última versión liberada es la 2.10 (en realidad la 2.10.1) mientras continúa el rumbo hacia el próximo gran lanzamiento, que será Mono 3.0.
Pero esta versión ya tiene grandes avances, como:
Soporte para el Google Native Client. Esta es una tecnología que permite ejecutar código nativo dentro del browser de manera segura, y que ahora incluye no sólo la posibilidad de ejecutar código compilado previamente, sino también realizar compilación a demanda (JIT), lo que permite que Mono soporte Reflection.Emit o los lenguajes dinámicos, por ejemplo.
Nuevo motor de Profiling Este nuevo motor está optimizado para trabajar en entornos de múltiples hilos y es muy eficiente en todo sentido.
Implementación mejorada de Sockets
Mejoras en el Parallel Framework y en SGen, el nuevo recolector de basura (una increíble pieza de ingeniería)
Se unificó el runtime de soporte para MonoTouch y MonoDroid (versiones de Mono para IOs y Android respectivamente)
Cecil/Light es una versión mejorada de Cecil, la librería que permite generación e inspección de código en tiempo de ejecución, y que muchos utilizan incluso en .NET, donde no tiene un equivalente directo.
Nuevo mecanismo del compilador de C# y enormes mejoras en el shell interactivo Mientras Microsoft lleva más de dos años preparando su compilador como servicio, Mono lo tiene disponible desde entonces, incluyendo una consola que ahora permite no sólo la ejecución de expresiones sino de programas completos. El servicio de compilación además dejó de ser estático, con lo que se pueden crear diferentes instancias del compilador con contextos separados.
Compilador de VB que permite compilar a los perfiles de VB 2.0 al 4.0
Soporte completo para ASP.NET MVC 3 incluyendo Razor y WebPages. Mono 2.10.1 agregó algunos detalles que permiten ejecutar el CMS de código abierto Orchard de Microsoft, que de esta manera puede ejecutarse también en Linux.
Implementación de WebMatrix.Data, una librería de Microsoft que permite acceso a datos aprovechando los nuevos tipos dinámicos.
Muchísimas optimizaciones para Mono en OS X, que aprovechan más los servicios particulares del sistema operativo de Apple.
Compilador de F# e intérpretes de IronPython y IronRuby completamente integrados en los paquetes para Linux y Mac.
Gendarme 2.10, el analizador estático de Mono, también es mucho más rápido y tiene 33 reglas nuevas.
Como ven, nadie puede decir que Mono no avanza.
Para más detalles, se pueden ver las notas de los releases 2.10 y 2.10.1 en el sitio de Mono.
O pueden ir directamente a la página de descarga, donde encontrarán paquetes de instalación para Virtual PC, VMWare, LiveCD, openSUSE, SLES/SLED, Windows, Mac OS, CentOS, Solaris u otras distros de Linux.
Aunque esta es una versión intermedia para corregir algunos temas menores, es una buena noticia ver que el proyecto sigue en marcha después de que Microsoft lo dejara por completo en manos de la comunidad, al liberar todos los fuentes como código abierto bajo licencia Apache 2.0.
Esta versión básicamente mejora la compatibilidad con Ruby 1.9.2 e incluso corta la compatibilidad con Ruby 1.8.6, lo que es una buena medida para seguir hacia adelante con menores dependencias. Si alguien necesita todavía compatibilidad con 1.8.6 puede seguir utilizando IronRuby 1.0.
Recordemos que tanto IronRuby como IronPython son ahora proyectos en los que Microsoft no participa más, quedando por completo bajo control de la comunidad, y liderados por Jimmy, Miguel de Icaza, Michael Foord, y Jeff Hardy.
El nuevo release mantiene las herramientas de integración con Visual Studio 2010, soluciona algunos problemas con la instalación de Gems, renueva por completo el parser (motivo de la decisión de soportar sólo 1.9.2) y arregla algunos problemas detectados en Windos Phone 7.
Después de un tiempo bajo un programa beta limitado, el equipo de Mono ha abierto finalmente la versión preliminar de MonoDroid para todo el mundo.
Con esta nueva versión preliminar, además, agregaron soporte para desarrollo en Mac OS utilizando MonoDevelop con el AddIn corespondiente.
Mono en Android instala la máquina virtual de Mono, con una versión reducida de las bibliotecas conteniendo sólo lo que tiene sentido en un dispositivo Android.
Además de permitir de esta manera programar en C# en lugar de Java (el único lenguaje completamente soportado por Google en Android), MonoDroid incluye una adaptación completa de las APIs de Dalvik (la máquina virtual de Android) con una interfaz mucho más familiar para desarrolladores C#, incluyendo propiedades, eventos, tipos genéricos, y realizando conversiones de manera automática cuando es necesario.
Aprovechando que se ha liberado y agregaron soporte completo para Mac, les dejo unas imagenes capturadas tras actualizar mi entorno y probar la aplicación que viene como plantilla (estilo Hello, World).
Así se ve la solución y la actividad principal inmediatamente después de crear un nuevo proyecto Android:
Se puede hacer debugging en emuladores o dispositivos reales. El SDK de Android trae emuladores genéricos y se pueden generar otros para modelos específicos obteniendo el kit del fabricante para Android. Motorola, por ejemplo, los provee para mi Milestone y otros dispositivos con Android.
En la práctica es muchísimo más rápido probar contra el teléfono. La primera vez tarda un poco más porque instala el runtime, pero las siguientes va mucho más rápido. Los emuladores me dan la impresión de ser unas 5 o 6 veces más lentos (al menos que mi teléfono). La ventaja de los emuladores es que se pueden capturar más fácilmente las pantallas, como en el ejemplo debajo, que muestra uno genérico recién iniciado:
Y finalmente, la emocionante aplicación de ejemplo, funcionando en el emulador. Cada vez que tocamos el botón incrementa el número de clicks. No está tan mal para ser algo que el entorno genera solo, sin tener que modificar un solo caracter:
Sobre el final del año inicio una serie que espero continuar desarrollando durante el incipiente 2011: Raros Lenguajes Nuevos.
La idea es dedicar cada tanto un post a algún nuevo lenguaje que aparezca en el radar, no necesariamente de los esotéricos, si no generalmente aquellos con posibilidades interesantes de ganar adopción o servir de campo experimental en ciertas áreas, aportando ideas que se incorporen en otros lenguajes más populares, como ocurre todo el tiempo en este campo.
En palabras de su creador, Vasily Voronkov: "Ela is a strict dynamically typed impure functional language" (un lenguaje funcional impuro, estricto y dinámicamente tipado). Y está implementado para correr sobre el CLR de .NET ó Mono. Analicemos estas características:
Dinámico se refiere a que los tipos se definen y verifican en tiempo de ejecución, no de compilación, y estricto se refiere a que las asignaciones (por omisión) no se difieren, sino que ocurren en el momento. Los tipos son además fuertes, es decir que no hay conversiones implícitas (no se pueden sumar números y strings, por ejemplo).
Exactamente al revés que en Haskell, que es funcional pero no-escricto (o lazy) por omisión, en Ela esta característica es opcional y debe ser explícita. Por ejemplo:
let x =(&2+2) let y = x *2//La expresión '2 + 2' se evalúa recién en este momento
El motivo de esto es que Ela está diseñado para ser funcionalmente impuro, también al contrario de Haskell. Esto significa que un programa puede tener efectos colaterales, o más simplemente, mantener estado (usar variables). Los lenguajes funcionales puros solamente admiten constantes y funciones, y no hay estado variable, lo que permite muchas cosas interesantes, pero implica un enorme cambio de mentalidad para cualquier programador que no proviene del mundo de las matemáticas.
Finalmente, la sintaxis general de Ela es relativamente parecida a ML (o el reciente F#), utilizando secuencias, líneas de ejecución y comparación de patrones. Un ejemplo para asustarse (aunque en realidad no es difícil de entender después de algunas reglas básicas, sería:
let filter f x::xs | f x = x :: filter f xs; |else= filter f xs; _ []=[]
Esto define una función filter que recibe un predicado, es decir una función que evalúa cada elemento en una lista para filtrarla. El uso de esta función para filtrar los elementos mayores que 5 es tan sencillo como:
let filter' = filter (>5)
Como siempre en programación funcional, se trata principalmente de describir el resultado a obtener más que detallar los pasos a seguir para obtenerlo, y Ela sigue bien esta tradición.
¿Qué diferencia a Ela de otros lenguajes?
Además de características funcionales típicas como funciones anónimas (lambdas) y closures, y aplicación parcial.
Sin embargo, Ela toma un decisión interesante respecto de cualquier otro lenguaje (que yo haya visto), y es que toda función debe recibir un único parámetro. No cero ni más de uno. Esto que parece bastante restrictivo se resuelve en forma general haciendo que una función reciba otra, generando encadenamiento, como en:
let res = sum 23// por supuesto, devuelve 5
pero no recibe dos parámetros, sino que sum recibe como entrada 2 y devuelve una función anónima que recibe como parámetro el 3. Veamos la definición de sum:
let sum x y = x + y
Esta es una técnica conocida como currying(que toma su nombre del matemático Haskell Curry, al igual que el lenguaje Haskell que toma la otra mitad). En programación funcional esta es una técnica muy usual para componer funciones, pero no es obligatoria.
A primera vista parece raro, si, pero el hecho de pensar que toda función recibe un único parámetro cambia por completo la sintaxis del lenguaje, ya que no hacen falta más paréntesis ni separadores, y esto tiene un montón de consecuencias interesantes de analizar (y obviamente plantea varios desafíos).
Otra interesante decisión de diseño es que todos los operadores son identificadores únicos, con lo que no hay posibilidad de utilizar un símbolo con diferente semántica en dos contextos. Por ejemplo, el operador "-" (signo menos) significa resta, por lo que el operador unario para indicar un número negativo es "--" (por ejemplo: --2). Raro otra vez, pero hay algunas razones válidas relativas a la capacidad de validación de expresiones en cualquier contexto.
Es importante destacar que aunque el intérprete es totalmente funcional y puede ser embebido en código .NET o Mono, el proyecto está aún en nivel experimental.
Miguel lanzó un nuevo blog personal especializado en el sistema operativo de Mac y el de iPhone/iPod/iPad, visto por supuesto, desde la perspectiva de Mono.
Como explica en el post inicial, las razones principales para tener un blog separado del suyo personal de siempre, exclusivamente dedicado a este tema, son dos:
Mientras que su blog está dedicado más que nada a novedades generales del proyecto Mono, éste está orientado a documentar sus experiencias específicas con estos ambientes de Apple, en un nivel de detalle más granular, que puede molestar a quien no tiene interés específico en el tema.
Estos sistemas operativos son propietarios y están bastante alejados de los ambientes abiertos usuales para gran parte del público anterior.
En cualquier caso, es muy interesante tener un buen recurso técnico con detalles sobre MonoTouch, la implementación de Mono y herramientas de desarrollo para programar aplicaciones para iOS en lenguajes .NET, que es un producto comercial (sobre todo por temas de licenciamientos varios), y MonoMac, que si es un producto abierto y gratuito para hacer lo mismo sobre Mac OS X (que sí es un sistema propietario).
Lo que ambos proyectos brindan, fundamentalmente, es la posibilidad de programar en C# y utilizar las librerías de la BCL, pero con bindings agregados para interactuar con el entorno de Apple en Objective-C y la interfaz de usuario Cocoa, lo que es una buena alternativa para quienes están interesados en desarrollar para estos dispositivos pero no tanto en aprender todos los detalles y lenguajes específicos.
Las noticias no están directamente relacionadas, pero fortuitamente ambos anuncios ocurrieron ayer.
Novell anunció haber sido adquirida por Attachmate, una compañía de servicios de tecnología, en 2.200 millones de dólares. Attachmate espera potenciar su portfolio de soluciones con las marcas y productos Novell y SUSE, pero un detalle muy interesante es que como parte de la misma operación, CPTN Holdings LLC, un consorcio de empresas de tecnología lideradas por Microsoft compró por 450 millones de dólares en efectivo un paquete de 882 patentes de tecnología de Novell.
Antes de ponerse muy nerviosos pensando en Microsoft tomando control de patentes alrededor de Linux, hay que tener en cuenta que Novell sigue teniendo un montón de tecnología de recursos de red, incluyendo un directorio de autenticación que es uno de los principales competidores de ActiveDirectory, y toda una suite de interoperabilidad entre el mundo Windows y Enterprise SUSE. Y por supuesto, Novell es el anfitrión del proyecto Mono y otros relacionados como Moonlight (la implementación abierta de Silverlight para Linux).
Casualmente, Miguel de Icaza anunció ayer la disponibilidad de la versión estable de MonoDevelop 2.4.1, la IDE para Mono que corre en Linux, Mac OS y Windows.
Esta versión aumenta soporte para xbuild (la versión Mono de msbuild), soporte a proyectos .NET 4, y mejoras generales en Mac OS X.
