DSLs en su lugar

Una "vieja" entrada del blog de Bertrand Meyer, necesaria de recordar cuando se habla de DSLs (Domain Specific Languages) con alguna liberalidad: en ocasiones se los propone para resolver problemas específicos  que parecen condenados a bufurcar el camino de trabajo. La posición de Meyer es radical: ¿cuándo crear un lenguaje de dominio? Nunca:
El contexto:

It is a common occurrence in software development. Someone says: “We should design a language”. The usual context is that some part of the development requires a rich functionality set, and it appears appropriate to provide a flexible solution through a specialized language.

La objeción de Meyer:

Designing a language in such a context is almost always a bad idea (and I am not sure why I wrote “almost”). Languages are endless objects of discussion, usually on the least important aspects, which are also the most visible and those on which everyone has a strong opinion: concrete syntactic properties. People might pretend otherwise (“let’s not get bogged down on syntax, this is just one possible form”) but syntax is what the discussions will get bogged down to — keywords or symbols, this order or that order of operands, one instruction with several variants vs. several instructions… — at the expense of discussing the fundamental issues of functionality.
Worse yet, even if a language will be part of the solution it is usually just one facet to the solution.As was already explained in detail in [1], any useful functionality set will naturally be useful through several interfaces: a textual notation with concrete syntax may be one of them, but other possible ones include an API (Abstract Program Interface) for use from other software elements, a Graphical User Interface, a web user interface, yet another for web services (typically WSDL or some other XML or JSON format).
In such cases, starting with a concrete textual language is pretty silly, since it cannot yield the others directly (it would have to be parsed and further analyzed, which does not make sense). Of all the kinds of interface listed, the most fundamental one is the API: it describes the raw functionality, excluding any choice of syntax but including, thanks to contracts, elements of semantics.

Conclusión:

One of the key rules for successful software construction — as for many other ventures of course, especially in science and technology — is to distinguish the essential from the auxiliary, and consequently to devote proper attention to the essential issues while avoiding disputations of auxiliary issues. To define functionality, API is essential; language is auxiliary.
So when should you design a language? Never. Well, hardly ever.

 Si computaramos el tiempo de trabajo para definir el DSL y asegurar que funcione, en tales contextos, la adhesión a la posición de Meyer es segura...

Cloud computing y soberanía

La reciente comprobación de la nula privacidad de las comunicaciones electrónicas, ya no sólo en el tráfico de datos, sino también en las comunicaciones telefónicas o incluso en el seguimiento de matrículas de autos, ha establecido un freno importante a la expectativa de uso de cloud computing. No estamos hablando ahora sólo de prevenciones en cuanto a la seguridad o disponibilidad de los datos y servicios, sino de la intromisión incontrolada en su contenido. La comprobación de que distintas oficinas de control de seguridad en múltiples países pueden acceder a datos privados sin mediar una orden judicial expresa, pone en duda cualquier plan de externalización de datos. ¿Pueden sus datos, bajo circunstancias especiales, estar sujetos a espionaje industrial?. Quizá sea hora de pensar dos o tres veces qué se pondrá fuera del control de una red privada.
Pablo Albarracín, en América Economía, puntualiza los problemas jurídicos relacionados con la normativa que cada país dicte para la protección de datos, destacando que estos se convierten en un problema de soberanía nacional:

El caso PRISM ha resucitado la preocupación sobre la soberanía de los datos. ¿Los datos que una compañía o gobierno considera estratégicos, deben estar en una nube internacional o en servidores y data centers dentro del territorio nacional? La masiva adopción del cloud, desde el popular Gmail a sofisticadas plataformas empresariales, está provocando una ambigüedad geopolítica de datos en todos los frentes. Dicho de otro modo, Snowden sacudió en la cara de todos los gobiernos y agencias de seguridad del mundo su deficiente soberanía informática.
El tema es más importante de lo que aparenta, puesto que pone en juego la reputación y confiabilidad del cloud como depositorio de los datos críticos, como pueden ser secretos militares, patentes industriales, información de los clientes de un banco o la información clínica de toda una ciudad o región. Una óptima adopción del cloud debería asegurar que los proveedores de la nube garanticen a sus clientes que los datos se alojen en el país de origen."La soberanía de datos se ha convertido en la principal preocupación para los clientes fuera de los EE.UU. que están buscando la adopción de una nube pública", dice el informe de Gartner Data Sovereignty Can Be a Hurdle for the Adoption of Cloud Computing. "Durante los próximos cinco años, los problemas de soberanía de datos disminuirán a medida que más proveedores pongan atención a este asunto. Sin embargo, el problema no va a desaparecer por completo".

De esta manera, tanto el cliente como el proveedor de la tecnología, evitan confusiones relativas a las diferentes normativas legales que cada país posee y que pueden generar problemas al momento de enfrentar un litigio (Google y Microsoft mucho saben de esto a raíz de PRISM). Más aún, cuando la oferta cloud está abarcando no sólo la capa de software (SaaS), sino que los niveles más físicos del cloud también cuentan con una oferta deslocalizada (IaaS, PaaS). La seguridad nacional puede estar en riesgo.
“Los datos no son de Google, los datos son de las empresas. Ellas son las dueñas de los datos y se responsabilizan de la información", dice Gabriela Franchetto, Google Enterprise Sales Manager. "Google se pone a disposición de ustedes (los clientes), pero los datos no son nuestros, sólo la infraestructura que los aloja”. (Conozca más sobre los aspectos legales y técnicos en la adopción del cloud en el reportaje: Leyes del Cloud Computing: ¿está la región preparada para subirse a la nube?)

Según el estudio Data Sovereignty and the Cloud de la University of New South Wales (UNSW) y el Cyberspace Law and Policy Centre, el lugar donde se alojan los datos es una problemática no sólo técnica, sino que legal y estratégica de un país. El tema ha dejado de ser asunto exclusivo de abogados a considerarse un punto importantísimo en gestión de riesgo, empresarial como gubernamental, situación que irá creciendo con los años.

Albarracín destaca la probable acción de Brasil expresada a través de su ministro de Comunicaciones, Paulo Bernardo Silva, de exigir por ley a sus proveedores de servicio de almacenamiento de datos de que éstos sean alojados en el país:

Según informó EFE, el ministro afirmó que el almacenamiento de los datos en el país es un asunto de soberanía nacional debido a que las empresas de internet se están negando a ofrecerle datos a la justicia brasileña con la disculpa de que sus archivos no están en el país. Bernardo se refirió a la reciente negativa de Google de entregar copias de un e-mail a un tribunal que investiga un caso de lavado de dinero. "Con esas denuncias (de Snowden) vimos que ellos (las empresas) entregan todo. Aquí alegan que no pueden hacerlo".
"Creamos incentivos para que los centros de datos se instalasen en Brasil y les suspendimos todos los impuestos sobre la compra de equipos, pero creo que ahora vamos a tener que obligarlos a almacenar los datos aquí". Bernardo señaló que además de obligar a las empresas a archivar sus datos en el país, el gobierno también va a invertir en infraestructura de  redes locales y a promover una reforma en la gestión internacional de internet, para que sea asumida por la ONU y no por Estados Unidos.

"El problema es que la internet tiene reglas de gestión exclusivamente dictadas por Estados Unidos. Defendemos una gestión multilateral y multisectorial. Países y sociedades tienen que estar representados, pero los Estados Unidos se resisten mucho y frenan cualquier intento de discusión sobre el asunto", puntualizó.

La probable exigencia de Brasil de radicar localmente los datos, de todas formas, no hace sino agregar una razón más a las dudas más que razonables de externalizar datos: localizarlos fronteras adentro no cambia el problema, sólo lo sujeta a las particulares exigencias de las agencias nacionales. Es decir: quien piense en externalizar, piense de nuevo. Y no sólo con un abogado, sino con un analista político.

Comienza el beta test para Plex 7.1

Simon Cockayne, Product Manager para Plex y 2E desde mayo último, anunció en estos días la convocatoria a clientes registrados para participar del test beta de Plex 7.1. Una buena parte de las mejoras programadas de incluír en la nueva versión están orientadas al soporte de .NET, WCF y Azure, y Kerberos en IBM i (AKA iSeries, ex AS400). De interés por lo tanto para todos aquellos clientes que utilicen estas variantes. Está programada también una nueva facilidad interna de la IDE: la creación de perfiles de configuración que puedan ser invocados de una lista. Esta es una solicitud de la comunidad que lleva tiempo en espera, que facilitará a todos el uso de variantes y versiones, libres de errores de configuración manual.
A la larga práctica de convocar a clientes y desarrolladores a los beta test de Plex y 2E, CA ha agregado el uso de técnicas ágiles de evolución y prueba del producto, que prometen ciclos más cortos de cambio. Otra parte clave de esta filosofía, es la inclusión del repositorio de ideas en la Comunidad Global de Plex/2e (y otros productos), en la que es posible postular mejoras y correcciones, con la habilidad de votarlas y ranquearlas.  Estas son tomadas en cuenta para la elaborar la evolución del producto.
Por lo tanto, están invitados a participar y adelantar los cambios propuestos...

RPG antes y ahora

Este año se cumplieron veinticinco años de la aparición del As400/iSeries/System i o cualquier otro nombre que se propongan agregarle. De su robustez y excelente diseño dan testimonio dos artículos recientes: uno dedicado a recordar sus primeros ensayos y nacimiento, y otro evaluando el estado actual del RPG como lenguaje moderno. El primero, escrito por Mel Beckman, recuerda su inicio como programador, participando en beta tests del equipo en una empresa cercana a Rochester. Sólo rescato dos párrafos:

Despite the plethora of early bugs, we RPG programmers quickly began to see their frequency decreasing as the S/38 OS, called CPF (Control Program Facility) stabilized. S/38’s single-level store, object-oriented architecture, and integrated database really did seem to make programs more reliable, heading off the most common coding gaffs and preventing wholesale machine crashes. As the S/38 matured, it gained a reputation for solid reliability in the finance and healthcare industries, which are still strong markets for the system’s descendent, today’s IBM i. Throughout the S/38’s evolution to AS/400, iSeries, and ultimately Power hardware architectures, IBM has been able to preserve customer’s investment in business logic and data storage.
I had no idea then just how powerful the S/38’s innovations would turn out to be. They enabled IBM, and its many customers, to transport an immense amount of binary code and data into the future – not just twenty-five years, but thirty years, with very few disruptions. IBM promised, with both the S/38 and the IBM i, to protect users’ business investment in applications, processes, and logic.
In the intervening decades, many other systems have come and gone, dragging their user populations into oblivion with them. Only IBM i has preserved a continuous architectural path that is still going strong today. In 2013 it’s clear that IBM alone kept it’s promise.

El segundo artículo es un editorial del IBM System Magazine, escrito a propósito de las celebraciones de los 25 años del equipo (sistema operativo + recursos + hardware), puntualiza el estado actual del RPG, que de ninguna manera es ya lo que inicialmente fue (generador de reportes):

In reading today’s anniversary chapter, Susan learned something new—although Jon claims he knew it long ago. When RPG IV was introduced, the name “RPG” was officially declared to be no longer an acronym—or, more correctly as Scott Klement pointed out recently, an initialism. For those who didn’t realize this, to be an acronym, apparently it must be pronounceable as a word, such as NATO. If it is simply spelt out, as RPG is, it’s technically an initialism.
While the letters RPG may not officially stand for anything any more, RPG, the language, means a great deal to many thousands of programmers around the world and the users of their rock-solid, efficient, modern business applications.
In many ways it’s a good thing that RPG no longer stands for “Report Program Generator” because it has been many, many years since RPG’s primary function was reporting. It has evolved radically over the years.
If the picture that comes to your mind when you think of RPG is of columnar logic with multiple conditioning indicators and nary a hint of SQL, it’s time to wake up, Sleeping Beauty—you’ve missed a lot in the last 25 years. IBM i’s modern RPG IV is barely recognizable as a relative of the AS/400’s original RPG/400.
Today’s RPG logic is written in free format. It also utilizes libraries of homegrown, open-source and third-party functions in addition to RPG’s own library of more than 70 BIFs (built-in-functions). As a result, what would have been dozens of lines of indicator-laden, columnar “old-style” RPG are replaced by simple, powerful expressions.  And RPG’s data access has “grown up” too. Support for a huge variety of native data types and a deeper level of integration with SQL than is seen in almost any other language makes RPG a natural partner for IBM i’s integrated DB2 database.
Still think that RPG = Green Screen? Think again. Many shops are running interactive Web and mobile applications with logic powered by RPG. Or if you prefer, RPG code can easily provide the business logic underpinnings of Web services, stored procedures and other services to applications written in PHP, Java, Python, Ruby, .NET, etc.
Inevitably there are things that RPG doesn’t understand natively and that IBM cannot add to the language in a meaningful timeframe. The pace of change in today’s IT world is just too fast. That’s why Open Access was recently added to the language. It allows for the development of drivers to add new functionality while maintaining RPG’s powerful data marshaling capabilities. For example, you can write a driver to call a currency conversion Web service from RPG, allowing any RPG program to treat access to real-time currency conversion data as if it were a huge database in the sky. Simply set the key values for the currencies involved and issue a CHAIN operation. The conversion rate is returned as if it were being retrieved from a database column.

Como los autores dicen, mientras hemos visto pasar y desaparece equipos, lenguajes y arquitecturas, el diseño conceptual del AS400 sigue vigente y en primera línea. Centenares de miles de instalaciones lo demuestran. Quizá aún a pesar de algún directivo de la propia IBM, que a veces parece dudar de su producto.