[Languages] Mi lenguaje de programación (Parte I – Ideas)

Hace algún tiempo que vengo pensando y me vengo autoconvenciendo de que el nivel de abstracción que normalmente se utiliza en el desarrollo de aplicaciones dirigida por los datos no es el adecuado. Este tema ya lo toqué en otros post sobre Domain Specific Language y sobre Software Factories así le doy una vuelta más de rosca y presento mi lenguaje de programación.

Veamos como se desarrolla un software: Nos llegan los requerimientos de nuestro Program Manager/Team Leader y, después de las reuniones de rutina y una vez que tenemos las ideas y los documentos,  llega la hora de echarle mano al código y entonces comenzamos así:

C# Code
using System.IO;


public class Product
{
   private string productName;

   public string Name
   {
       get {...} 
       set {...} 
   }
}

La pregunta es: puede ser esta la manera más natural de especificar el comportamiento y las cualidades de un componente de catálogo de productos? No estaremos hilando demasiado fino? Es más, me atrevo a preguntar: no debería estar hecho ya por alguien más o es que acaso nadie nunca escribió un producto que trabajase con productos?. Está bien, acepto que para algo así falta mucho, que habria que estandarizar bloques de construcción y un montón de cosas más pero la pregunta inicial sigue en pie. Son los lenguajes de propósito general los adecuados para todos los casos particulares? Claro que no. Aquí es donde entran, entre otras cosas, los DSLs o Lenguajes específicos de un dominio.

A mi humilde entender, no es posible seguir construyendo software como lo venimos haciendo hasta ahora, reescribiendo bloques de código enteros, con un nivel de abstracción bajísimo y todavia muy lejos del lenguaje natural, tiempos largos, costos altos, impedancias de todo tipo (All vs. OOP); lo que resumiendo es calidad pobre. 

Pienso que una alternativa a todo esto es la generación automática de mucho (realmente  mucho) código y en este punto entran los DSL (Domain Specific Language), lenguajes especialmente diseñados para un propósito muy particular como SQL, HTML, UML, COBOL y otros (por favor no piensen en DSL Tools porque no estoy hablando de ellos, o al menos no solo de ellos).  

De repente hoy existen un gran número de lenguajes de propósito general con frameworks, paquetes, componentes, librerias para todo lo imaginable pero con un poder expresivo que no se compara con el de un lenguaje de propósito particular. Por ejemplo, en DBase III+, Clipper y Fox Pro podemos hacer cosas como esta:

USE CLIENTES
DISPLAY FOR CODIGO > 50000 TO PRINT

(imprimir el listado de todos los clientes cuyo campo codigo es mayor a 50.000)

El problema (y la ventaja) con los lenguajes de propósito general es que nos llevan a trabajar a un nivel de detalle que muchas veces es innecesario, al escribir una clase creamos un campo y debemos decidir si es int, float o double y luego crear la propiedad que muchas de las veces es un simple recibir y devolver el valor crudo del campo, innecesario!. Al pensar en una factura, todo el mundo piensa en un papel,  en un documento comercial, en un impuesto, en la agencia federal de ingresos públicos, mientras que los informáticos pensamos en una cabecera y un conjunto (colección, array, etc) de items con productos, un cliente, y un mapeo a la DB. Estamos acostumbrados a pensar en términos de las herramientas que utilizamos!

Como deberíamos codificar una factura? se me ocurre que de una manera algo mágica considerando «el estado actual del arte» podriamos declararla así:

XN Code
package Business 
{ 
    entity Factura persistent
    { 
        field readonly auto id ID;
        field options ('A' | 'B' | 'C') type; 
        field date operationDate;
        field numeric total;
        field numeric discount;
        field ref(Customer) customer;

        entity Item *
        {
             field numeric count;
             field numeric unitPrice;
             field numeric total;
             field ref(Product) product;

             init: count = 1;
             invariant: count > 0;
             invariant: unitPrice >= 0;
             invariant: total >= 0;
             let: total = count * unitPrice; 
        }

        init: operationDate = DateTime.Now;
        invariant: discount >= 0 and discount <= 100;
        invariant: Item.Length > 0;
        let: total = Item:{item| t+=item.total, return t; } * (100-discount)/100;
    } 
}

Este no es un pseudo código sino la visión de un lenguaje declarativos que estoy comenzando a definir. Como puede apreciarse, este es un lenguaje sencillo de un gran poder expresivo y que sirve principalmente para declarar la metadata para una posterior fase de compilación que generará código y sí, este es un lenguaje orientado a entidades o simplemente un DSL para el desarrollo de entidades de negocio. Este lenguaje mezcla el concepto de entidad con expresiones similares a OCL para la especificación de invariantes y otros constraints.

Alguna ideas sobre el lenguaje XN

  • Los generadores de código se nutren de medadatos para hacer su trabajo, por lo general, estos metadatos son los de las bases de datos, es decir, se genera código a partir de la estructura de una base de datos. Cuando se necesita reestructurar el sistema se debe modificar la estructura de la base de datos  y generar todo de nuevo perdiendo así parte de la lógica de negocios más elemental como los invariantes, los cálculos sencillos, las inicializaciones y los constraints. Todo esto no parece muy natural.
  • Las entidades se componen de otras entidades utilizando composición. Esto es, la entidad contenedora controla el ciclo de vida de la entidad contenida tanto en memoria como a nivel de base de datos. Cuando una entidad se elimina, todas las entidades contenidas por esta también se eliminan. Cuando una entidad se va a salvar en la base de datos, se inician transacciones para salvar también a las entidades contenidas, en otras palabras, una entidad es una unidad atómica.
    Solo se puede acceder a una entidad contenida a traves de su entidad contenedora.
  • La persistencia en la base de datos debe ser transparente al desarrollador. Parece una locura y puedo estar de acuerdo con todos aquellos que piensan distinto y que saben argumentar bien sus puntos de vista pero es hora de buscar una solución radical al problema y yo creo que esta es una opción: generar la base de datos junto con el código. Esta alternativa presentará problemas para extender las aplicaciones pero es muy factible generar automaticamente los scripts de migración ante un gran cambio en las entidades.
  • La estrategia de carga de las entidades debe ser inteligente. Ante la pregunta, Lazy load o no? cada cual tiene una respuesta como: «ver cada caso y estudiar en que puntos conviene y en cuales no», «yo nunca uso lazy load, cuando me hace falta algo lo cargo», «es muy bueno tener el modelo de objetos completo en memoria», «el muy lento, incrementa el tráfico en la red y casi siempre trae cosas que no vamos a necesitar», etc. Pienso que el sistema debería llevar estadísitcas de las consultas y actuar en concecuencia de manera inteligente y liberar al desarrollador para que piense en los requerimientos reales. 
  • No me agradan las siguientes cosas: ORMs, código legacy, One-off development, aplicaciones de negocios en lenguaje C, migraciones de aplicaciones, ni XML for all. Por otro lado, pocos desarrolladores son a su vez DBAs, expertos en .Net, Java, Python y PHP.
    Con un lenguaje declarativo como XN que genere código a partir de templates e integradas a entornos como VS2008 es posible mitigar algunas de estas limitaciones de gustos y/oo experiencias. 

Escribiré más sobre esto apenas tenga algo de código.

Lucas Ontivero

Sin categoría

13 thoughts on “[Languages] Mi lenguaje de programación (Parte I – Ideas)

  1. Saco mi bola de cristal, y cual brujo de feria, vislumbro que estas pasando por un momento dramático en el desarrollo de software. La bola de cristal me dice, entre penumbras, ideas nebulosas, y algunos binarios que:

    – Podrías estar trabajando en este momento con VB6
    – Podrías estar trabajando en este momento con clases de 15.000 líneas de código
    – Podrías estar trabajando en este momento con bases de datos sin una estructura estable, sin PK ni FK, ni nada.
    – Podrías estar trabajando en este momento con aplicaciones cliente/servidor que dicen trabajar en el servidor, pero en realidad pasan como texto plano contraseñas al cliente y vuelven al servidor.

    Todo esto te frustra, y te obliga a hacer este tipo de cosas (como las que planteas). 🙂

    Ahora, sacando la joda (Que clavado que le pegue 😉 )

    Debo decir que con esto me tiraste el juego navideño a la m#@@#$a

    Quiero ver más de esto.

  2. Hola Matias,
    Tu bola de cristal es una maravilla! Pero dejame decirte que la locura es independiente de los proyectos en los que estoy trabajando 😉 Espero tener aunque sea el parser listo antes de fin de año para con eso poder empezar a probarlo y encontrarle todas las falencias de la sintaxis.

    Un abrazo loco.

  3. La verdad es que Microsoft cada vez me da mas que pensar, que tengamos que desarrollar toda la capa de acceso a datos en una verguenza, a estas alturas no disponen ni siquiera de un modelo de datos en condiciones, a ver si el EDM funciona en condiciones, pero no lo creo, es una pena que tengamos que perder el tiempo en diseñar esto. A mi me ha costado casi 12 meses y lo que me queda. Alucinante. Al final me doy cuenta de que lo único que quieres es vender y vender, a costa de inovar, pero nada de mejorar y ayudar a los desarrolladores a que se trabajo sea mas facil, es increible, me dan ganas de volver a mi antiguo dbase, cuanto tienen que aprender.

  4. Juan, te pregunto. Que tiene que ver Microsoft con el post de Lucas?

    Me refiero a que Lucas propone un lenguaje orientado a entidades. No se si estas regañándolo por algo ??, o simplemente tienes alguna frustración de final de año y la mejor vía de escape fue pegarle a Microsoft, en un blog que coincidió con C#, lenguaje patrocinado por la empresa.

  5. Si y me parece muy bien el modelo que propone Lucas, lo único que digo es que esto que el propone es una necesidad que tenemos desde hace mucho tiempo y nos enfrentamos a ella desde diversas aproximaciones, no entiendo como al dia de hoy todavia estemos así, es decir creo que Microsoft no aporta lo suficiente para poder trabajar con entidades y modelos de datos, los suyos todavia tienen bastante que desear y me parece un paso atras, creo que los lenguajes tipos a dbase y otros han conformado soluciones muchos mas fáciles, yo vengo de Foxpro y despues de mas de 5 años trabajando con .net puedo afirmar que este se encuentra a años luz de lo que nos aporta .net en cuanto al manejo de datos se refiere, por supuesto no quiere decir que este en contra de .net si no no estaria trabajando con el, pero estoy muy descontento con su filosofia de inovar, inovar y no mejorar sus productos.
    Desde luego estoy muy frustado, porque con las herramientas de desarrollo actuales me cuesta mucho mas trabajo desarrollar lo que antes hacia de una forma mucho mas rápida y optima ahora me cuesta mucho mas trabajo, y no, no no estoy regañando a nadie, simplemente expongo mi opinión y me pregunto porque estamos continuamente reinventando la rueda, si la mayoria de nosotros tenemos las mismas necesidades, y me meto con Microsoft por dos razones la primera porque creo que hay que empezar a ser un poco críticos con los que hacen, pienso que no aportan herramientas adecuadas para trabajar con modelos de datos robustos y creo que deberian pararse a mejorar este tipo de cosas que tanto me afectan.

    Y ademas lo c

  6. Asi es Matias, estoy frustado, porque trabajo desde hace mas de 20 años con herramientas de acceso a datos, muy lejos del nivel tecnologico de empresas como Microsoft y me parece increible que modelos como los que propone Lucas, no existan, ya que es una necesidad de muchos desarrolladores, los que trabajamos con datos hemos de desarrollar modelos y soluciones similares a la que proponen en el articulo, me parece alucinante que tengamos que trabajar en desarrollar modelos de entides, con una empresa del nivel de Microsoft, en la que por cierto invierto bastante dinero en comprar su productos y por supuesto critico en aquellos aspectos que creo que peor funciona, de hecho el EDM que van a sacar dentro de poco biene a dar solución a todas estas carencias que los desarrolladores demandan, y creo que tienen mucho que aprender de lenguajes como dbase, clipper y otros en el que algunos procesos sobre todo los relacionados con datos estan a mi juicio a años luz de las soluciones actuales de Microsoft.

    Una pregunta no seras tu, uno de los defensores aferrimos de Microsoft que pienan que todo lo que hacen esta bien verdad ???

  7. Hola Juan,

    para nada, no defiendo a muerte nada. Solo mis ideas :), pero de cualquier creo que lo que MS esta haciendo es correcto.

    Ten en cuenta que los lenguajes, y sabia que iba por ese lado, como FoxPro, DBase, Clipper, y Cobol (entre otros), cumplen justamente la regla que Lucas plantea. Me refiero a que nosotros usamos C#, VB.net, o similar, los cuales son lenguajes GENERICOS, se suponen que podrían o deberían poder hacer cualquier cosa. Por este motivo, algunas de esas cosas serán más fáciles, o más difíciles de lograr, mientras más genérico sea el lenguaje.

    Ahora, y lo que dices es una discusión muy común con gente que ha usado Fox durante mucho tiempo. Porque recién ahora, por ejemplo, con LinQ, se quiere arrimar la bocha un poco mas a lo que Fox ya hacia desde que nació?

    Creo que la respuesta es, entre muchas respuestas, simple. Y esto es tratar de mantener el lenguaje en el foco de genérico. Ya en la nueva versión de .Net, el lenguaje cambio para poder aceptar LinQ. Pero cambio para que siga siendo genérico, pero con soporte a datos. Imagínate que pasaría si C# pasara a trabajar como lo hacia Fox. Que pasa conmigo si quiero hacer un juego?

    En fin, no creo que MS no quiera innovar en ese sentido. Por el contrario, creo que lo esta haciendo, y no lentamente, sino que lo hace rápido en comparación con las peripecias que tiene que hacer para que el lenguaje siga siendo multipropósito.

  8. Estoy deacuerdo con lo que expones, pero la necesidad que existe de herramientas adecuadas para manejar datos nos hace tener que apostar por lenguajes c#.net o vb.net de forma «obligatoria», ya que han abandonado herramientas como «fox» para ofrecer lenguajes que te permitan ademas de manejar datos otro tipo de cosas, pero yo comparo mis tiempos de desarrollo con .net, y te aseguro que en muchos aspectos, no solamente en cuanto al manejo de datos, herencia y otros factores .net esta muy lejos de este tipo de lenguajes. Cosa que no entiendo, porque me hacen trabajar en aspectos que antes estaban bastante mejor resueltos y de algún modo me obligan a desarrollar en .net, ya que hoy dia no existen alternativas mejores para trabajar con datos o al menos yo no las conozco, por eso critico que no hayan aprovechado algunas de las cosas que estos lenguajes realizaban de una forma mas adecuada, o al menos mas sencilla. Mucha gente ha tenido que apostar por herramientas tipo NHibernate y similares para no invertir mucho tiempo en el desarrollo de estas capas, con lo que eso implica, y lo digo despues de trabajar mas de 4 años con c#, de haber desarrollado sistemas para dispositivos móviles, comercio electrónico, aplicaciones windows, y otros, que desde luego en lenguajes como fox no podrian si quiera plantearse. Pero creo que no es normal que en el año 2007 estemos buscando soluciones adecuadas para estos problemas comunes a la mayoria de los desarrolladores, aunque es solo mi opinión.

    Siento haberme desviado tanto del articulo.

  9. Bueno gente, la variedad de nuevos problemas y sus soluciones de hoy han hecho desaparecer lenguajes como Fox Pro. Como bien dice Matias, juegos, web services, antivirus y cualquier tipo de aplicaciones son imposibles de realizar en un xbase por lo que parece que la soluci’on pasa por modificar o extender los lenguajes para darles nuevas funcionalidades o volverlos multiparadigm’aticos. Yo no creo que sea esta la mejor solución sino que deber’ian existir un conjunto de DSLs muy pequenos y sencillos para cada una de estas cosas manteniendo los lenguajes bien establecidos como est’an hoy por hoy.
    El intentar por todos los medios de darles mayor expresividad es un error seg’un yo lo veo. Que en c# tengamos declaraciones como:
    var names = from c in cust….
    var name = «Pablo»;

    No puede mas que crear un montruoso lenguaje con una especie de hibridaci’on que se parece algo a un lenguaje script.

    La otra alternativa es seguir creando frameworks, cosa que parece m’as natural pero que continua en la misma direcci’on

  10. Lucas, muy copada tu propuesta, ahora, sos de otro planeta, porque ponerte a hacer el compilador para tu lenguage, solo los muy grosos tienen esas intensiones.
    Metele para adelante y solucionos la vida a todos, pero hacelo OpenSource, jajaja, pero cobra una guasada de soporte, jaja.
    Cuidate!

  11. Coincido plemnamente con tu idea, (tambien estoy estudiando NBusiness).
    Dale un vistazo al link de la especificacion de OASIS.
    En uno de los apendices esta su gramatica.
    Esta especificacion es utilizada para la generacion automatica de aplicaciones http://www.care-t.com (con otras especicaciones añadidas). Pero a mi solo me interesa (en principio) lo referente al lenguaje.

    No desanimeis en vuestro empenyo!!!

    http://www.elpais.com/articulo/tecnologia/software/espanol/genera/programas/modelos/conceptuales/elpcibtec/20040129elpcibtec_3/Tes/
    http://www.dsic.upv.es/users/oom/index_old.html
    http://www.dsic.upv.es/users/oom/oasis.html

  12. Hola OASIS Version 3.0. Gracias por comentar, ya he leido la nota en elpais y me he dado unas vueltas por los links que me facilitaste (muchas gracias por estos) aunque no he leido mucho todavia porque estoy en el trabajo 🙁

    En cuanto a NBusiness, que te puedo decir, me gustó mucho la idea en un principio y hasta le envie a Justin la gramatica del e# para que lo pusiese en codeplex, pero no estoy de acuerdo con la forma en que implementa las templates ni que las logica de negocios se deba escribir en metodos est’aticos entre otras cosas. Claro que ese proyecto avanza muy pero muy bien y es una linda opcion.

    Saludos.

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *