MPL 1: Una prueba de concepto

Hace algunas fechas os comenté acerca del planteamiento base, por ahora aún es algo naif y quiero aprovechar el proceso para aprender mas sobre la materia, lenguajes, compiladores y entroncarlo con mis avances en accesibilidad.

Un ejemplo de código vale más que mil palabras, así que voy a tratar de hacer aquí hoy una prueba de concepto en forma de carta a los reyes magos, sencilla, pero que servirá de base para implementarlo posteriormente (con NodeJS en primera instancia), para luego evolucionar desde ahí.

Hola “mundo” en MPL

¿Como no voy a usar este manido ejemplo? xD, vayamos a ello. El fichero helloWorld.en.mpl contendría lo siguiente:

/* 
	
MPL - Concept Exploration
21 03 14 Raúl Carrillo aka metsuke
  
A basic document with a single button
*/

const headerLevel = 1; // "H1"

var messages[] = with (mplTextCollection) {
  .addMultilangString('Hola Mundo');
  .addMultilangString('Titulo Principal');
  .addMultilangString('Prueba de concepto');
}

var action = with(mplAction) { 
  .addAlert(message);
}



var document = with (mplDocument) {

  .addTitle(headerLevel,messages[1]);
  
  .addParagraph (messages[2]);

  .addButton(messages[0], action);
  .render();
}

En esencial se definen las cadenas de texto (cuya estructura nativa es multiidoma), se declara la acción a tomar al pulsar el botón, se define el interfaz (titulo, texto y botón) y se renderiza.

Una de las particularidades de MPL debe ser el agnosticismo respecto del lenguaje de programación final, esto es, este interfaz, así definido, debe ser compilable en su correspondiente html + css + js, una calculadora científica, en un zx spectrum, en C++ para Linux, en java, en C# para windows 210 en entorno de escritorio o en ese mismo para consola (o en un libro de elige tu propia aventura impreso en papel, si nos curramos el traductor adecuado).

MPL no buscar ser un lenguaje interpretado, sino que busca generalizar el desarrollo al tiempo que especializa todo lo posible el código fuente resultante que a su vez es procesable del modo habitual en cada plataforma. Tendré tiempo de ir definiendo todo esto, peor la idea importante es que escribimos código que define lo que debe ocurrir, no el como ocurre, eso queda a detalle en los traductores a cada uno de los entornos.

Por otro lado, me gustaría llevar MPL a un nivel superior, aplicar el multiidoma al propio código, de modo que cada variable tendrá la opcion de ser definida en distintos idiomas y cada clase del sistema debe disponer también de su propio sistema de traducción. El autor de una librería podría escribirla en ingles, y que un grupo de voluntarios la traduzca, no tengo nada claro el formato final, pero, de forna transparente MPL debe ser capaz de usar el código anterior y el siguiente con una relación de identidada entre ellos:

/* 
	
MPL - Prueba de Concepto
21 03 14 Raúl Carrillo aka metsuke
  
Un documento básico con un único botón
*/

constante nivelEncabezado = 1; // "H1"

variable mensajes[] = con (mplColeccionTextos) {
  .añadeCadenaMultiidioma('Hola Mundo');
  .añadeCadenaMultiidioma('Titulo Principal');
  .añadeCadenaMultiidioma('Prueba de concepto');
}

var accion = with(mplAccion) { 
  .añadeAlerta(mensaje);
}



var documento = con (mplDocumento) {

  .añadeTitulo(nivelEncabezado,mensajes[1]);
  
  .añadeParrafo (mensajes[2]);

  .añadeBoton(mensajes[0], accion);
  .renderizar();
}

Como concepto, el desarrollador podría trabajar en cualquiera de los idiomas soportados por el cóidigo concreto e ir cambiando a través de un simple botón, pudiendo hacer cosas como escribir en inglés por resultar mas conciso y pasar a español para mostrar un ejemplo , un equipo podría traducirlo a Hindi y usar el ejemplo en escuelas desde temprano en el iodoma nativo del alumno. Las posibilidades son infinitas.

Sin embargo, la mayor virtud de MPL ha de ser su enfoque nativo a la automatización y agregado de conocimiento, el modo en que esta pensado busca poder, por ejemplo, incorporar nueva evidencia científica sobre el modo de gestionar la interacción en un determinado modelo para personas ciegas y, tras implementar la metodología en los traductores, todo el código de todas las aplicaciones NATIVAS hechas en todo el mundo, se pueda reescribir de una sola vez.

Como digo las implicaciones de ese coste de mantenimiento casi cero son prometedoras, aunque no carente de aristas, como la necesidad de que el “desarrollador” deje mucho más en manos de MPL el diseño estructural, mientas se centra en aspectos puramente funcionales y de aspecto dentro de lo permisible.

Nada que no se haga ya en muichos frameworks, pero pretendo llevar esto a un nivel tal que no haya forma, a través de MPL, de crear nada no accesible al 100%, haciendo extremadamente rentable desarrollar una multiplataforma real y, además, impedir que nuestro código final se quede obsoleto, ya que siempre podremos recopilar… pero esa es otra historia.

Ahora me toca no solo definir todo esto, sino aprender lo que ya existe, no trato de reinventar la rueda, pero si usarla de un modo inesperado y ejemplar. ¡Al lio!

Quizá te interese ...

Dejar una Respuesta

XHTML: Usted puede usar las siguientes etiquetas: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>