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.

Privacidad de datos y Cloud Computing

del último número de Dr Dobb's, comentario de un usuario:

 From the beginning, I have always questioned the pros and cons of the cloud and their services. I have my doubts concerning security, privacy, corporate fortitude, and price and rule changes of cloud providers. Your discussions have moved me further away from these services and have added extra nails to their coffin.
— JLONERO8255, Dr. Dobb's member

Expresado en las respuestas y comentarios al artículo Through a PRISM darkly.

Del propio artículo:

The first and most profound effect will be a serious reconsideration of the wisdom of putting data into the public cloud. The previous argument for migrating data and apps to the cloud was that cloud hosts, such as Amazon, Google, and Microsoft, are much better at defending their systems from hackers than most corporate IT departments are. This view is supported by the contention that those companies can afford to hire hundreds of security professionals to provide the necessary protection, vigilance, and intelligent response — while most IT organizations can hire perhaps a few dozen, with no real ability to scale response in times of attack.
This argument, taken by itself, is still valid. However, it can no longer be taken by itself. A new dimension has appeared; namely, that the government can more or less at will see the contents of communications and data held on servers at cloud hosts. The important factor is that the government can gain this access without ever notifying the target company that its data has been copied to government servers.

Cada uno que ajuste sus propias cargas...

UML en la ICSE 2013

Anteúltimo día de ICSE 2013 (International Conference on Software Engineering) , que muestra un gran número de trabajos de interés y participantes. A esta hora, destaco el que Timothy Lethbridge comenta, aunque por razones diversas: la presentación de Marian Petre "UML in practice", que resume su investigación sobre una muestra de desarrolladores de software, respecto a su uso o no de UML. En el resúmen de Timothy

She conducted an excellent interview-based study of 50 software developers in a wide variety of industries and geographical locations. Her key question was, "Do you use UML".

She found that only 15 out of 50 use it in some way, and none use it wholeheartedly.

A total of 11 use it selectively, adapting it as necessary depending on the audience. Of this group use of diagram types was: Class diagrams: 7, sequence diagrams: 6, activity diagrams: 6, state diagrams: 2 and use case diagrams: 1.

Only 3 used it for code generation; these were generally in the context of product lines and embedded software. Such users, however, tended not to use it for early phases of design, only for generation.

One used it in what she called 'retrofit' mode, i.e. "Not unless the client demands it for some reason".

That leaves the 35 software developers who do not use it (70%). Some reported historical use, and some of these did in fact model using their own notation.

The main complaints were that it is unnecessarily complex, lacks and ability to represent the whole system, and has difficulties when it comes to synchronization of artifacts. There were also comments about certain diagram types, such as state machines being only used as an aid to thinking. In general, diagram types were seen as not working well together.

She did comment on the fact that UML is widely taught in educational programs.

Como Tijs van der Storm comenta, quizá Marian esté martillando los últimos clavos en el ataúd de UML...

También coinciden en sus comentarios James Noble,  Alex Nederlof, y Leif Singer, entre otros. Éste último apunta al uso de UML en educación registrado por Marian, como muchas veces, y en muchos aspectos, corriendo detrás de la situación real.

Android, nueva IDE?

 Oficialmente presentado en Google IO, el soporte de Android a una nueva IDE: IntelliJ IDEA, agregada a la existente sobre Eclipse. De lo que en distintas fuentes informales se puede inferir, no se trata de una IDE mas, sino de una preferente. Aunque parece ser que para los desarrolladores de Google es una excelente noticia (1, 2, en algún caso con alguna reserva,3), no estoy muy seguro que lo sea para un buen número de desarrolladores o empresas que hoy usan Android sobre Eclipse, no sólo por lo bien o mal que Android se puede usar sobre esta IDE, sino por el soporte que Eclipse ofrece en otros tipos de proyectos, que usualmente estarán conectados con Android. El valor de Eclipse está en la fuerte comunidad de desarrollo abierto, que ha montado sobre la IDE centenares de proyectos en el terreno del modelado, o de la infraestructura al  servicio de la construcción de estos proyectos. No sé si el  impacto de este cambio ha sido pesado de manera correcta.
En todo caso, si observo el tipo de críticas de los "googlers" a Eclipse, diría que están dispuestos a avanzar sobre IntelliJ con preferencia, dejando atrás a Eclipse si no es capaz de responder en sincronía a nuevos desarrollos. De sus dichos no se desprende un abandono de éste, sino un "soporte relegado".
En demérito del cambio se debería señalar que la comunidad de soporte de IntelliJ tendrá por lo general una extensión menor que la que Eclipse tendría...y que estamos hablando en este caso de una empresa comercial, de la que Android está tomando la parte de su producto que está puesta en open source. ¿Es esta una gran idea, estratégica? ¿Es comparable el alcance de la apertura y extensibilidad de uno y otro? Lo pongo en duda.
Una política que ha restado contínuamente seguidores a Microsoft es la de efectuar cambios a sus productos que dañan a su comunidad de usuarios (lo más evidente y profundo, el cambio de Win32 a WinRT). Parece ser que Google está jugando con el mismo estilo.
El anuncio del equipo de IntelliJ, en su sitio y su blog.

Wikipedia y la programación

Parece ser que, en Wikipedia, no hemos logrado el respaldo de los mejores escritores en algunas áreas de programación. En OOP, desde el mismo concepto hasta varios de sus elementos constitutivos, aparecen débilmente definidos: encapsulamiento, herencia, polimorfismo, interfaz, y varios otros. Quizá se podría decir que más interesante que el artículo en sí, es, en cada caso, la discusión entre los redactores y observadores. Creo que sería más conveniente la creación de un grupo de trabajo con respaldo en buenos conocimientos, que discutiera un enfoque general común, y mantuviera un plan de redacción unificado y consistente, que abarque el problema con mejor sustento teórico, y un plan homogéneo de casos y ejemplos. No parece recomendable en varios casos, acudir a Wikipedia en busca de una respuesta. En este caso, es preferible la versión inglesa.

Treinta años de Internet

Ariel Torres, en La Nación, comenta y rememora la creación de los protocolos que dieron lugar a Internet, hace treinta años, es decir, en enero de 1983. Coincidiendo con el inicio de la época en que el eje se desplazaba de mainframes o equipos de rango medio a las PCs, donde todavía reinaba IBM. Recuerdo las discusiones en revistas técnicas de networking, donde todavía ARPANET era el centro de la actividad: las nuevas perspectivas aparecían muy prometedoras desde su mismo inicio. Y aún faltaba para la WWW, y tampoco se hablaba todavía de la "autopista de la información". Habla Ariel Torres:

Fue un enero como cualquier otro, con noticias de primera plana, como la erupción del volcán Kilauea (cuya lava todavía hoy continúa fluyendo), el retiro de tenista Björn Borg de las canchas, el arresto del criminal nazi Klaus Barbie en Bolivia y la sentencia a cadena perpetua de 25 miembros de las Brigadas Rojas, en Italia, por el asesinato de Aldo Moro. Hubo también noticias menos relevantes, relacionadas con unas máquinas que se venían vendiendo como pan caliente desde agosto de 1981, las IBM/PC. En efecto, en enero de 1983 salía la primera versión de la planilla de cálculo Lotus 1-2-3 , que pronto se transformaría en una herramienta ineludible de la informática personal.
Detrás de estas noticias grandes y pequeñas, locales e internacionales, ocurrió algo sobre lo que no hubo crónica ni titular, pero que transformaría nuestra realidad, en los siguientes 30 años, más allá de lo que nadie por entonces se atrevía a imaginar. El primer día de 1983 nació Internet. O, dicho de otra forma, se completó la migración de los protocolos usados en Arpanet (los NCP, por Network Control Program) a los protocolos de Internet, los hoy bien conocidos y universalmente usados TCP/IP.
Arpanet, que había sido puesta en marcha el 29 de octubre de 1969 a las 10 y media de la noche , y que es considerada la antecesora de Internet, había comenzado a mostrar sus limitaciones en los primeros años de la década del '70. En 1973 se puso sobre la mesa la idea de que se necesitaba renovar la tecnología de tal modo que la transmisión de paquetes de datos pudiera realizarse no ya entre hosts (computadoras, por así decir), sino entre redes de computadoras. De hecho, la palabra Internet proviene de ese concepto, el de internetting , conectar redes entre sí, lo mismo que la frase red de redes para referirse a Internet.

Vinton Cerf, Lawrence Roberts (promotor de Arpanet), Bob Kahn y Tim Berners-Lee (creador de la Web) en 2002, cuando recibieron el Príncipe de Asturias. (Foto y leyenda de La Nación)

Vinton Cerf y Bob Kahn fueron los responsables de crear el nuevo conjunto de protocolos, es decir, la nueva tecnología de conexión a la que hoy llamamos, simplemente, Internet. Empezaron a trabajar en el proyecto en el verano de 1973, bosquejando las ideas básicas, que durante los siguientes 4 años se formularían, codificarían y consolidarían. En noviembre de 1977 se hizo el primer experimento conectando tres redes mediante TCP/IP, una en Noruega, otra en Inglaterra y la tercera en los Estados Unidos.
En total, les llevó 10 años y un ejército de programadores el crear, implementar y migrar a los TCP/IP; esto es, poner en marcha Internet. Pero cumplieron a rajatabla con el plan que se habían impuesto y el primer día de enero de 1983, aunque no salió en los diarios ni se le dedicó un instante de TV, este esforzado equipo de hombres y mujeres plantó los cimientos de una tecnología que cambiaría el mundo para siempre.
La falta de cobertura no fue, sin embargo, una falla de los periodistas. Por entonces, la recién nacida Internet era un experimento académico, tan lejos del resto de nosotros como los viajes espaciales, y ciertamente mucho menos atractivo. Una cosa de científicos. Habrían de pasar otros 7 años antes de que el público pudiera conectarse a la red de redes en los Estados Unidos. En la Argentina, que había sido conectada a Internet en 1990, los accesos a particulares llegarían en 1995. Es decir, 12 años después del nacimiento de la Red. Puede leerse (en inglés) el plan de migración de NCP a TCP/IP en este histórico documento .

 En Wikipedia en español hay una historia que debe complementarse con su versión inglesa. En la versión en castellano hay un cuadro de ARPANET que muestra el estado previo de las redes públicas.
Sólo mencionado al pasar: observo que el concepto "autopista de la información" están explicados de manera muy diferente en inglés o en castellano. Mucho que hablar sobre la preparación de artículos para Wikipedia...