LayerD documentation

I'm releasing a new SDK that contains a Programmers Reference Manual for Meta D++ and a revised guide to Compile Time programming for .NET programmers.
This reference manual is only in Spanish and was made by Belén Licari, thanks Belén! I've revised most of it and it seems ok ! I will update the manual if I find mistakes.
This is not much documentation taking into account the extension of the project but it's something :-). If someone can help me translating this documentation to English it will be great!!

Interactive compilation and RAD tools with LayerD

PD: new SDK coming soon: classfactory debugging, several bug fixes, Java to Meta D++ compiler, basic manual about OO in Meta D++ (in Spanish), more samples.

PD2: I know, this is English... I don't have time to write both Spanish and English so I have to make a choice. ... In fact I don't have time to write in one single language :-P

Dentro de LayerD

Estos días – y para no perder la costumbre – ando muy escaso de tiempo o energías suficientes como para dormir cuatro horas por día :-P. Por tanto, el post será corto cosa que – créanme – no es una de mis características tener capacidad de resumen para bien o para mal.

En el link posteo un PowerPoint que presentamos el año pasado en la UTN-FRC cuando realizamos la primera presentación en sociedad de LayerD (aún sin permitir al público tocar ni siquiera los binarios jeje).

Fueron muy poquitas personas a la presentación lo cual es de esperar teniendo un título para la charla que no es "muy comercial" y la mala difusión que tuvo. Lo importante del PPT que posteo es que habla de muchas cosas las cuales no están documentadas en otro lado – al menos en la web y que recuerde :-P – y si bien sin su "speech" relacionado no todo se entenderá o tendrá sentido, imagino que puede ser útil para comprender la tecnología LayerD.

Recuerdo que dicha charla se había planeado como de una hora y media con un recreíto a la mitad, lo cierto es que fueron tan pocas personas que no queríamos que corrieran en el recreo J y además en ese momento ni lo pensé y seguí hablando sin parar y luego mis compañeros Demian, Lucas y Alejandro. Fue bueno ver que casi nadie se fue antes de terminar – tal vez no se fueron para no dejarnos solos J – a pesar de que hablamos largo rato.

En la charla presentamos varios ejemplos funcionando incluyendo un programa multiplataforma de manejo de archivos que corría sin cambios en Java y NET, una librería activa para conexiones a bases de datos usando ADO.NET, lenguajes de dominio especifico para interfaces gráficas, una estructura para ejecutar fácilmente instrucciones de código en hilos separados, un par de ejemplos en Argentino! (lenguaje LayerD que en este momento se encuentra abandonado lamentablemente), ejemplos de refactoring de código usando classfactorys interactivas, un programa que se corregía a sí mismo si tratábamos de llamar a miembros inexistentes de clases por cometer errores de esctitura, entre otros.

El PPT habla un poco los modulos de salida, de la clasificación de los modulos de salida, de las características principales del lenguaje Zoe y Meta D++, el proceso de compilación de un programa Zoe, los tiempos de compilación. Más importante quizás es que intenta explicar porque necesitamos poder construir software abstracto.

LayerD no es un proyecto pensado o construido a la ligera, no es un lenguaje de programación más, o un generador de código o una utilidad para el programador. Muchas cosas se han tenido en cuenta y se han debido de solucionar para poder hoy empezar a tenerlo funcionando, en cuanto se posean los compiladores y módulos de salida desarrollados al nivel adecuado podrá construirse cualquier tipo de software desde un sistema operativo hasta un blog J, con los compiladores y módulos de salida actuales puede desarrollarse cualquier aplicación .NET J y prontamente Java. Lamentablemente, tengo tan poco tiempo de documentar el proyecto que todos los días me veo superado. Por otro lado, de a poco la falta de documentación va mejorando, ya tengo prácticamente un manual básico de Meta D++ que apenas tenga tiempo de revisar publicare, también estoy trabajando en actualizar la Especificación más formal de Meta D++ (que implícitamente especifica Zoe) y los viejos tutoriales del sitio web. Me alienta saber que si estuvo bien pensado, LayerD debe de resistir el paso del tiempo y lo peor que puede pasar es que alguien más lo reinvente uniendo todas las piezas que une LayerD y quizás realice un mejor trabajo y nos beneficiemos todos.

Quiero cerrar este post tratando de graficar todo lo que LayerD significa y con pocas palabras. Sé que eso es casi imposible porque el proyecto es una visión a mediano y largo plazo para la ingeniería de software, encarnada en herramientas sí, pero no se trata tanto sobre las herramientas sino en cuestionar técnicas, herramientas y formas de solucionar los problemas en la implementación de software. He aprendido que no es sencillo mostrar porque hace falta avanzar en software abstracto, porque LayerD es un camino para llegar a ese objetivo – claro espero no el único – y porque debemos de invertir en ello. Con un poco de suerte y trabajo, espero que en los próximos años quien no use una tecnología similar a LayerD al producir software tenga una gran desventaja competitiva en relación a quienes si lo utilicen y entonces, cuando alguien más visionario lo haya demostrado, el resto comprenderá que no es posible moverse en un mundo de cuatro dimensiones teniendo en cuenta sólo tres o al menos no es posible llegar a todos lados J.

Aquí va el link al PPT.

Guerra de Sintaxis, LayerD no va a la guerra

Desde que aparecieron los primeros lenguajes de programación en la década del 50 aproximadamente - dejando de lado otros antecedentes históricos que pueden considerarse - todo el mundo ha discutido sobre la conveniencia o no de diferentes sintaxis a utilizar en los lenguajes de programación.
Lo cierto es que a la hora de diseñar la estructura léxica y sintáctica de un nuevo lenguaje de programación - hablando siempre de lenguajes cuya sintaxis es textual - deben tomarse decisiones de compromiso. Una decisión típica que debemos tomar es elegir si nuestro lenguaje será fácil de escribir o fácil de leer, o al menos eso hacemos.
La sintaxis de un lenguaje de programación es importante en muchos sentidos:

• Es la cara visual del mismo
• Si gusta a los programadores a la hora de escribir los programas sumará al lenguaje en popularidad.
• Si es fácil de leer será más fácil mantener el código. Por el contrario, si es complejo de leer la manutención se dificultará.
• Como en general se dispone de una única sintaxis puede limitar la adopción del lenguaje por muchos programadores a los cuales no les agrade inicialmente.

A lo largo del tiempo cada lenguaje ha tenido que defender sus diseños sintácticos, por citar un ejemplo transcribo una porción de un manual de Python:

...The indentation rule may seem unusual at first glance to programmers accustomed to C-like languages, but it is a deliberate feature of Python, and one of the main ways that Python almost forces programmers to produce uniform, regular, and readable code. It essentially means that you must line up your code vertically, in columns, according to its logical structure. The net effect is to make your code more consistent and readable (unlike much of the code written in C-like languages). To put that more strongly, aligning your code according to its logical structure is a major part of making it readable, and thus reusable and maintainable, by yourself and others. In fact, even if you never use Python after reading this book, you should get into the habit of aligning your code for readability in any block-structured language. Python forces the issue by making this a part of its syntax....

Se podrían citar decenas de ejemplos más, en definitiva cada uno de los lenguaje dirá lo mismo "que buena que es esta sintaxis en comparación con el lenguaje X por bla, bla, bla, bla".
A partir de ello uno podría preguntarse porque no han surgido lenguajes de programación para los cuales se puedan usar más de una sintaxis. El problema con éste enfoque es la complejidad que implicaría el mantenimiento si no contamos con algún mecanismo que vuelva transparente la traducción entre diferentes sintaxis, además del aumento en la dificultad a la hora de capacitar a los programadores.

En última instancia el gusto personal de cada programador convierte la tarea del diseño de la estructura léxica y sintáctica de un lenguaje en algo mucho más cercano al arte y la subjetividad que a la ingeniería.

Personalmente, siempre me molesto tener que seguir una sintaxis en particular a la hora de programar para determinada plataforma y también me he preguntado porque debemos usar la misma sintaxis para escribir un programa que para leerlo. Lo cierto que ya transcurrieron más de 50 años desde la aparición de los primeros lenguajes de programación de alto nivel y parece que todavía discutimos que estilo sintáctico es mejor para un lenguaje de programación cuando en realidad desde el punto de vista de un compilador y un entorno de ejecución la sintaxis utilizada para construir un programa es algo totalmente irrelevante. Los pilares de cualquier lenguaje de programación o entorno de ejecución son su estructura de tipos y las características semánticas asociadas. Me da toda la sensación que a estas alturas de la historia deberíamos de haber pasado a la adultez en la ingeniería de software y poder utilizar libremente diferentes sintaxis de acuerdo a nuestro gusto, humor y proyecto en el cual estemos trabajando. Tampoco deberíamos limitarnos a utilizar la misma sintaxis para leer los programas que para escribir, sencillamente es mucho más eficiente utilizar diferentes formatos para la escritura que para la lectura.

En la actualidad, al menos en cuanto a entornos de programación populares, la única plataforma que ofrece cierta libertad a la hora de elegir la sintaxis es .NET de Microsoft. También se puede nombrar varios lenguajes de programación para la plataforma Java. Quizás, la limitación de estos lenguajes que apuntan al mismo entorno de ejecución es la falta de herramientas automatizadas para la traducción entre ellos, adicionalmente no siempre las características semánticas son completamente compatibles entre los diferentes lenguajes. Adicionalmente, no se poseen herramientas que nos permitan utilizar diferentes sintaxis para leer los programas de manera sencilla o al menos usadas de forma masiva.

Por estas razones, a la hora de diseñar LayerD quise asegurarme de poder utilizar múltiples sintaxis y evitar esas largas discusiones sobre que sintaxis es mejor para escribir un programa o que sintaxis es más adecuada para leerlo y mantenerlo. El 99,9% de los lenguajes de programación actuales combaten en la guerra de sintaxis desde que nacen, con un poco de suerte en el caso de los lenguajes de alto nivel dentro el framework LayerD eso no será así.

LayerD no va la guerra de sintaxis.

Con LayerD se puede elegir entre diferentes sintaxis para escribir los programas y se posee una multitud más de formatos para leerlos. Ok, en sus primeros meses no se poseerán muchos lenguaje LayerD de alto nivel - llamados meta-lenguajes - ya que en la actualidad disponemos del meta-lenguaje Meta D++ - el cual posee una sintaxis heredada de C++ y en parte de Java y C# - y el lenguaje Argentino - cuya sintaxis es tipo pascal pero en español, Ok necesito que Lucas Forchino termine esto que me lo prometió :-) - te quiero amigo jeje -, y finalmente más cerca de mediado de año se contará con un clon de C# el cual implementará un subset de la sintaxis de C#.

Esto es posible por la naturaleza modular de LayerD y la necesidad de todo meta-lenguaje de generar código en el lenguaje intermedio Zoe. Es interesante mencionar, que construir un meta-lenguaje para LayerD es relativamente sencillo ya que sólo se requiere programar un analizador léxico y uno sintáctico, luego el compilador Zoe se encarga del resto.

Para no olvidarnos de los problemas que nos pueden traer aparejado tener varias sintaxis para programar en una misma plataforma, la mayoría de los meta-lenguajes podrán traducirse de forma automatizada a otros meta-lenguajes utilizando el compilador Zoe y su proceso de "compilación interactiva" - lo cual es toda otra historia con muchos cuentos interesantes para otro día :-).

Tampoco me olvide de encarar la idiotez sintáctica en los lenguajes de programación y utilizando hojas de estilo se pueden leer los programas escritos en cualquier meta-lenguaje y compilado al código intermedio Zoe con un formato diferente al de escritura y por tanto optimizar la sintaxis para lectura y análisis de un fuente. Poseer una estructura sintáctica diferente para la lectura de un programa LayerD es tan sencillo como contar con una hoja de estilo aplicada al código Zoe que es XML.

Con suerte muchos programadores estarán de acuerdo en terminar con las guerras sintácticas y empezar a utilizar plataformas que permitan decidir que sintaxis utilizar cuando se escribe un programa y que formato visual usar a la hora de leer y examinar programas. LayerD provee un empujón a dicho enfoque permitiendo tener múltiples sintaxis de alto nivel a un costo relativo bajo - desarrollar un meta-lenguaje -, permitiendo traducir entre ellos de forma automatizada y abriendo la puerta para empezar a diferenciar lo que nos conviene a la hora de escribir programas y a la hora de estudiarlos.

Espero comentarios y pensamientos al respecto, si tengo tiempo amplio el post con gráficos y ejemplos de LayerD.

PD: 29/4/2008 se publicará en éste blog o el sitio web de http://layerd.net la primera versión binaria publica de los principales compiladores del framework LayerD así todos pueden empezar a jugar.....y a insultar los bugs.