Un patrocinador para Freya

Si trabajas en una empresa lo suficientemente grande como para que pueda asumir el reto, quizás a tu jefe... o a tí, si eres el jefe, le pueda interesar patrocinar el proyecto Freya.

¿Qué motivos puede haber para patrocinar un proyecto de este tipo?

1. Históricamente, muchos de los lenguajes de programación de los que ahora disponemos han surgido del mecenazgo de importantes empresas tecnológicas, que no eran exactamente consultorías especializadas en Informática. Los casos más conocidos son los de AT&T, de donde salieron C y C++, y el del Departamento de Defensa de los Estados Unidos, que fue la cuna de Ada.


2. Ayuntamientos de grandes ciudades, o comunidades autónomas, pueden encontrar interesante el proyecto. Por una parte, muchas veces funcionan como grandes empresas, y se suponen que apoyan la iniciativa empresarial, la creación de puestos de trabajos, etc, etc. Conozco, por ejemplo, un proyecto de entorno de desarrollo y compilador para COBOL, patrocinado en su momento por la Comunidad Valenciana, y los ejemplos de patrocinio de distros de Linux son muchos.


3. Para una empresa, puede ser interesante el patrocinio gracias a las ventajas fiscales de este tipo de ayudas.


4. Y están las ventajas obvias: publicidad, tanto en Internet como en libros y cursos, material de formación gratuito para la empresa, etc, etc.


5. ... y observe que no entro, deliberadamente, en las ventajas técnicas: una empresa con un potente departamento de software puede beneficiarse enormemente por disponer de una tecnología como la de Freya. Incluso no se trata ya del propio lenguaje: está la experiencia en el propio entorno, la posibilidad de crear lenguajes especiales dependientes del dominio, el desarrollo de herramientas para lenguajes existentes, como verificadores estáticos, analizadores de flujo, etc. Incluso empresas que comercializan un producto de software pueden utilizar este know how para incorporar lenguajes de script en su producto principal.

Claro, todo depende de cuánto sea necesario gastar en el patrocinio. Pues bien, las cuentas pueden salirle incluso en este sentido. Objetivamente, el gasto mínimo consistiría en un apoyo salarial para un programador durante un plazo de un año (luego hablaré de plazos y objetivos). Al no ser necesaria una dedicación al 100%, ni siquiera se trata de un salario completo (con los extras de retenciones fiscales, seguridades sociales, etc, etc). No voy a hablar de cifras en público, pero tenga presente que estoy hablando de una fracción de un salario.

¿El estado del proyecto? El compilador está prácticamente terminado. Durante el año del patrocinio, el objetivo sería redondear un entorno de desarrollo propio (completando SharpBlade) o adaptar el compilador para su uso dentro de Visual Studio o SharpDevelop. Ya hay bastante trabajo hecho en esta dirección, por supuesto.

Por último, hay otra opción posible: si le interesa adquirir derechos sobre Freya, incluso sobre el producto completo. No es la opción que veo más probable, pero es posible, y sería cuestión de negociarlo.

Busco trabajo

Busco trabajo como programador, analista o jefe de proyecto. 18 años de experiencia laboral demostrables. Pueden ser proyectos como freelance o a tiempo completo o parcial. Motivo: hartazgo de funcionar como empresario y que Hacienda se lleve casi todo lo que gano.

Mi nombre es Ian. Mi actual empresa es IntSight. Mi dirección de correos es mi_nombre arroba mi_empresa puntocom.

Lo pequeño y lo grande

¿Ha visto ya las noticias sobre Microsoft Surface? Por si le da pereza seguir el enlace, o si no tiene ahora mismo una conexión decente a Internet, le resumo la idea: se trata de un ordenador sin teclado ni ratón. Tiene pequeñas cámaras bajo el cristal de protección que siguen los movimientos de los objetos que entran en contacto con el cristal. De esa manera distinguen los dedos de otros dispositivos con los que pueden interactuar.

Aunque no parezca complicado a simple vista, algo tan sencillo abre muchas puertas... e introduce algún que otro problema. En un ordenador convencional, hay un único cursor para el ratón. En la superficie, por el contrario, se pueden usar simultáneamente varios dedos. Es posible que dos o más personas utilicen simultáneamente la superficie, mientras que nuestros ordenadores asumen por lo general que los está manejando un único usuario.

Mientras veía el vídeo pensé en cómo estaría implementado el software del sistema. Naturalmente, bajo la superficie (nunca mejor dicho) hay un Windows Vista, pero me refiero al lenguaje en que se programan las aplicaciones especializadas para esta plataforma. Y me he dado cuenta de otra ventaja con .NET que los antiguos programadores de Delphi no teníamos:

Suponga que retrocedemos a la época anterior a .NET. ¿Cómo accederíamos a las nuevas APIs desde Delphi "clásico"? Lo más probable es que la nueva API residiese en una DLL. Por lo tanto, los programadores Delphi tendrían que esperar a una traducción de las cabeceras de C++ a Pascal para poder hincarle el diente. ¿Cuánto tiempo se tardaba, típicamente, en aquellos gloriosos años? Tenga en cuenta, además, que muchas veces estas interfaces traducidas contenían errores de traducción: ocurrió en su momento con el software de la mismísima Borland.

En claro contraste, esta traducción no es necesaria en .NET. Da igual el lenguaje con el que haya sido programado el API de la superficie: cualquier lenguaje .NET (¡sí, incluyendo Freya!) puede empezar a trabajar con el API, pues la traducción es automática, sin necesidad de intermediarios.

¿Una insignificancia? Puede. Pero sin importar lo pequeña que sea, se trata de una ventaja, o más bien, de una de las muchas pequeñas ventajas de la migración a .NET. A veces la cercanía a los árboles nos impide disfrutar del bosque.

---

De momento, se trata de un dispositivo caro. Al parecer, Microsoft empezará implantándolo en hoteles y bares de "alto standing". He visto también una aplicación de un dispositivo parecido, si no es el mismo, para implementar un sintetizador, en una universidad española. El punto fuerte del sintetizador era que permitía que varias personas lo "tocasen": no usaba teclas, sino que "respondía" al contacto con los dedos y con figuras geométricas predefinidas, a modo de fichas.

It's just a spring clean for the May Queen

There's a feeling I get
when I look to the West,
and my spirit is crying for leaving...

LALR

¿Tiene alguno de vosotros código que funcione para un generador LALR? Sí, ya sé que hay unos proyectos por ahí equivalentes a yacc/bison... pero me llevaría demasiado tiempo retocarlo y adaptarlo. El tiempo que no tengo ahora.

El caso es que tengo una idea de "producto": un generador de compiladores especialmente adaptado para .NET. ¿Cuál es el problema? Cuando se trata de compiladores .NET, o creas un compilador recursivo descendente, a mano (o con alguna ayuda de herramientas), o utilizas un analizador LALR(1), que suelen ser más potentes. Pero en este último caso, te encuentras un problema: el analizador suele llamar a un conjunto de rutinas para construir un árbol durante la compilación. Y esas rutinas por obligación reciben todos sus parámetros como valores de tipo object o de alguna clase base más o menos igual de primitiva. Como resultado, tienes que estar ejecutando conversiones dinámicas de tipos todo el tiempo. No se trata tanto de la pérdida de velocidad, que al final no es tanta, sino de la pérdida de seguridad, robustez, etc, etc. En un entorno nativo, podías realizar conversiones estáticas (arriesgándote a recibir un error en ejecución si te equivocabas), pero esto no es posible en .NET.

Hay otro problema: el modelo de desarrollo. Quien crea un compilador de esta manera tiene que programar, por una parte, la gramática "a secas". Luego de ejecutar la herramienta que la convierte en código ejecutable, tiene que ocuparse de establecer las correspondencias entre reglas de la gramática y rutinas semánticas. En sistemas más "primitivos", como el yacc, podías escribir las rutinas junto con las reglas. Sin embargo, GOLD Parser Builder, a pesar de ser una herramienta mucho más agradable de usar, sigue la filosofía de separar reglas y rutinas, en beneficio de la independencia del lenguaje.

Mi idea es crear un generador de compiladores basado en un lenguaje propio, de estilo funcional (es lo más adecuado en estos casos). Para cada no terminal de la gramática, se establecería un tipo para los nodos que generaría. Entonces, el generador podría crear pilas separadas para cada uno de los tipos asociados a las reglas. Así se evitaría el problema de las conversiones.

Por otra parte, por muy poca potencia que le des al lenguaje, se logra mucho. Como el objetivo de los "programas" es generar una estructura de datos arbórea, la mayoría de las llamadas serán a constructores. No es necesario que el lenguaje tenga "lazy evaluation", porque el algoritmo de análisis bottom-up garantiza que los parámetros de llamada a cada constructor ya estarán evaluados antes de esta llamada. Además, teniendo ya experiencia en compilar código para .NET sería extremadamente fácil que la herramienta crease directamente módulos o ensamblados, listos para utilizar, sin necesidad de pasar por un fichero intermedio con código fuente en otro lenguaje.

¿Alguien se anima?

¿Cuánto son dos más dos?

... y ahora pretenderán que los que siempre respondimos "cuatro" nos alegramos de que finalmente no hayan sido cinco.

Cuando yo no trabajo, no cobro. Pretender que en España alguien dimita por un error, aunque sea por tamaño error, es ser muy inocente. Pero al menos que no cobre. Que no cobre ni un duro de salario, que vaya a La Moncloa en el metro de Aguirre y Gallardón, que se olvide de los helicópteros del ejército para ir a ver los toros o a su mujer haciendo los coros, hasta que todos aquellos con los que ha estado impúdicamente coqueteando durante estos meses estén donde siempre debían haber estado: en la cárcel, o entre las seis tablas de madera de un paralelepípedo oblongo.