martes, febrero 28, 2006
lunes, febrero 27, 2006
Java no está orientado a componentes
Habría que empezar distinguiendo entre "Java lenguaje" y "Java plataforma". Esto que voy a plantear ahora es una de las críticas a Java como lenguaje: Java no es un lenguaje "orientado a componentes".
¿En qué consiste tal presunta carencia? Sostengo la teoría fácilmente verificable sobre el avance por olas de la Programación Orientada a Objetos. Obviemos las olas "prehistóricas", es decir, aquellas anteriores al éxito comercial de C++. Tendríamos entonces:
- En la primera ola, el modelo de lenguaje sería C++ (para bien y para mal): strong typing, herencia múltiple, soporte opcional para golosinas sintácticas como sobrecarga de operadores o sobrecarga de métodos... En mi opinión, Eiffel, a pesar de ser concebido como un antídoto al hartazgo de C++, pertenecería a esa primera ola. Esta es una simplificación exagerada, por supuesto, pero va a sernos útil. De entrada, porque en muchos sitios sigue idolatrándose a C++ como el culmen de la P.O.O.
- No hay mucho acuerdo sobre esto, pero en mi opinión, el siguiente paso revolucionario lo da Alan Cooper con Visual Basic. No fue un invento con glamour, pero aportó la idea de componente. El fallo de Cooper fue no pensar que las ideas que aportó sobre interfaz visual podían afectar al lenguaje subyacente. Quien dio ese paso fue Anders Hejlsberg con Delphi, y ya conocemos la consecuencia: la supremacía absoluta de un lenguaje comercial durante una buena temporada.
¿En qué consiste la idea del componente? La industria del software saliva como el perro de Pavlov cada vez que alguien menciona la metáfora electrónica, de modo que vamos a utilizarla una vez más. Si la aparición de las clases y objetos de la primera ola se puede parangonar con el invento del transistor, la entrada en escena de los componentes es el equivalente en software de la aparición de las primeras placas o circuitos impresos. Cuando era niño, tuve una larga temporada en la que me aficioné a la electrónica. ¿Ha probado alguna vez a implementar un circuito determinado (un amplificador, un pedal para guitarra) con transistores y otros componentes electrónicos habituales... pero sin usar una placa apropiada? Es la placa lo que hace posible, por una parte, una implementación rápida y limpia, sin interferencias, del circuito. Por otra parte, la placa permite acelerar la fabricación de estos circuitos. Sin el circuito impreso, no tendríamos los microprocesadores actuales.
Traduzcamos la idea al mundo del software. La idea del componente consiste en formalizar las técnicas que utilizan las instancias de clases para interactuar entre ellas. El problema es que estas interacciones, sorprendentemente, no se pueden simular directamente con los recursos de la P.O.O. de la primera ola. Por una parte, tenemos el concepto de evento. Java no tiene eventos, hablando con propiedad, y obliga a implementar este tipo de interacción a través de tipos de interfaz y clases anónimas. El concepto de evento no sólo es útil para los componentes al estilo VCL o Windows Forms, sino que incluso ha demostrado ser útil, en una de sus muchas variantes posibles, en COM+.
¿Y las propiedades, qué pintan en todo esto? La raison d'être de éstas es la serialización, que es, a su vez, lo que hace posible la configuración inicial de un componente con la ayuda de un Inspector de Objetos. ¡Java tampoco tiene propiedades! Nos obliga a trabajar con pares de métodos: GetText/SetText para lo que podría ser simplemente una propiedad Text.
¿Por qué Java omite estos recursos tan probadamente útiles? Es probable que la culpa la tenga el rígido control que ejerce Sun sobre su lenguaje. De no ser por este exceso de celo, estas carencias se podrían resolver rápidamente. De todos modos, no son los únicos problemas de Java como lenguaje. Tampoco la evolución de la P.O.O. se detuvo en la segunda ola. Más adelante escribiré sobre la tercera ola, en la que, curiosamente, Java sí tuvo una influencia decisiva.
¿Café para todos?
Abriré fuego en la próxima anotación...
lunes, febrero 20, 2006
Fetichismo del IDE
¿Quiere más detalles sobre las causas del terremoto en Borland? Por si no me he expresado con la suficiente claridad, repito: es la propia Borland la principal culpable. Varias ideas nocivas se introdujeron, por desgracia, en el depósito de memas (unidades de información con capacidad de replicación) compartidas. Una de estas memas asesinas es la siguiente:
"Borland debe su éxito a los Entornos Integrados de Desarrollo."
Tropecé con esta curiosa idea por primera vez durante el accidentado período de prueba de Delphi 8, y el portavoz fue el mismísimo Danny Thorpe, el jefe de equipo que acaba de abandonar Borland por Google. Desarrollemos la frase, tal como ocurrió en aquel foro:
- Borland no debe su éxito al compilador de Delphi. Ni siquiera al diseño del lenguaje.
Bien: tenga presente que se trataba de la época en la que, presuntamente, Borland ganaba una pasta con JBuilder. En JBuilder, Borland no ponía el diseño del lenguaje: JBuilder es Java, un lenguaje celosamente controlado por Sun. No soy un experto en Java: no puedo asegurar que, al igual que Borland hizo luego con C# Builder, JBuilder utilice un compilador ajeno... aunque es muy probable. En todo caso, al igual que ocurre ahora con los lenguaje para .NET, la complejidad de un compilador para la JVM es mínima comparada con la de un compilador de la vieja escuela, para C++ o Delphi. Para un ejecutivo Borlandiano en aquella época era muy tentador concluir que no importa ni el compilador ni el lenguaje en sí: ¡JBuilder era la demostración fehaciente!
Esto es un error de mucho cuidado. JBuilder, para empezar, es un producto con mucha trampa. Sospecho que gran parte del dinero que se ganaba con JBuilder provenía de los acuerdos con Oracle y el JDeveloper... es decir, de un mercado cautivo: si comprabas el Oracle, pagabas automáticamente por el entorno de programación en Java, aunque luego no lo sacases de la caja y usaras Delphi para las aplicaciones en el lado cliente.
Hay una forma directa de desmontar esta teoría: apunte en un papel los motivos por los que eligió, en algún momento, invertir su tiempo en Delphi. Esta es mi lista:
- Compilador: mi primer contacto con Borland se remonta a mi época de universitario. En aquella época, había poco para elegir en el apartado de compiladores para PCs. Conocí UCSD Pascal, Turbo Pascal y C; más adelante llegarían C++ y Modula II, y casi al final, Eiffel. El compilador de C que comencé a utilizar era de Microsoft. La diferencia en velocidad de compilación era enorme... y lo peor de aquel compilador de C era que tropezabas con "Internal Error" en cuanto complicabas un poco la sintaxis de tus expresiones. Es cierto que estaba aquel asunto del "compilador integrado con el editor": fue una idea ganadora en su momento, cuyo crédito pertenece a Borland. Pero seamos objetivos: esto no sirve de apoyo a la tesis de Borland ("lo nuestro son los IDEs") porque aquel "compilador integrado" tenía muy poco que ver con los actuales IDEs. En cualquier caso, Microsoft copió la idea al poco tiempo, en su línea de compiladores Quick.
- Compilación y enlace: Turbo Pascal partía con desventaja como lenguaje. Mientras Turbo Pascal sólo permitía generar aplicaciones monolíticas, cualquier versión de C permitía compilación por separado, y generaba ficheros obj que podían combinarse con un enlazador. Es cierto que el formato obj de Intel era (y es) una tragedia ambulante, y el proceso de compilación y enlace era lento y penoso. Eso dio un respiro a Borland en cuanto pudo generar unidades compilables por separado: el formato tpu que ideó simplificaba y aceleraba el enlace, y evitaba los problemas relacionados con el uso de cabeceras compilables en C y luego en C++.
- El lenguaje: un estudiante suele aceptar las herramientas que le recomiendan sus profesores, de manera que lo que pueda decir sobre mis preferencias como estudiante no tiene demasiada importancia. Pero incluso en aquella época, era opinión general que Turbo Pascal, como lenguaje, debía mejorar mucho para ponerse a la par de C++, que empezaba a destacar por entonces. El caso es que, una vez graduado, comencé a usar C++ con mayor frecuencia, preferiblemente con el compilador y entorno de Borland. ¿Era el entorno lo importante? No: era el lenguaje. Necesitaba un lenguaje potente para mis primeros proyectos profesionales. Y si había un buen entorno de desarrollo, mejor que mejor, pero no era lo decisivo.
De hecho, cuando apareció Delphi, me sorprendió programando casi en exclusiva con C++ (y con una variante limitada de C para un sistema CAD llamado Microstation). Para Windows usaba Borland C++. Ya había probado el Visual Basic... pero la pobreza del lenguaje era disuasoria. Lo que me atrajo de Delphi fue el lenguaje: aunque no era tan potente como C++ (y juro que al trabajar por entonces en algoritmos geométricos lo lamenté mucho), la funcionalidad mejoraba muchísimo lo que ofrecía Pascal... y sobre todo: tratándose de un producto de Borland, todos esperábamos mejoras constantes en esta dirección.
Esto es muy importante. Recuerdo que todos aplaudíamos la valentía de Borland al mejorar constantemente la funcionalidad de sus lenguajes. De C++ ya se había apoderado un comité de estandarización, y lo llevaba por la calle del dolor: C++ crecía desmesuradamente, sin tino, y sin embargo, no daba todas las respuestas necesarias para programar en los nuevos entornos gráficos de Windows 3.11 y luego Windows 95. Borland no tenía esos problemas: si hacía falta un nuevo tipo de método para manejar mensajes, se añadía a Pascal, y punto. Borland C++, en cambio, tenía que respetar las reglas del estándar, y obligaba a usar macros indescifrables para interceptar los mensajes del sistema operativo.
Observe que acabo de mencionar una de las principales razones del éxito de Borland:
Borland controlaba por completo su propio lenguaje, Pascal/Delphi, y lo adaptaba continuamente para mejorar el soporte para su principal sistema operativo.
Esta historia de amor y odio entre Borland y Windows comenzó con los ya mencionados "métodos de mensajes", pero no se detuvo ahí. El siguiente hito se produjo en Delphi 3, cuando Borland añadió los tipos de interfaz al lenguaje y creo DAX, la biblioteca de soporte para desarrollar en COM/ActiveX. El resultado: si usted necesitaba crear un servidor de automatización OLE, era mejor usar Delphi que recurrir al compilador de la propia Microsoft. ¿El entorno? ¡Qué más da! La magia estaba en el lenguaje... y en su infraestructura de soporte: la biblioteca de clases asociada.
¿Cuán fácil o difícil lo tiene Borland ahora, con .NET, para continuar esta tradición? Hay que reconocer que es complicado:
- Borland sigue teniendo el control del lenguaje. No obstante, es poco lo que puede hacer para diferenciarlo del resto de los lenguajes .NET. Seamos sinceros: la sana costumbre de sorprendernos con cambios interesantes en el lenguaje de una versión a la siguiente ha pasado a Microsoft... probablemente con Anders Hejlsberg, el originador de la misma.
- Igual de difícil es la posibilidad de mejorar la llamada infraestructura del lenguaje. En la época de Windows, la alternativa a la VCL y el DAX era el horrible API nativo de Windows y un engendro llamado ATL en cuyo dominio los ángeles no osan entrar. Ahora, sin embargo, la alternativa a la inestable y limitada VCL.NET es la (por lo general) elegante biblioteca de clases de la plataforma.
Hay una trampa en lo que acabo de escribir: he asumido que el futuro de Delphi debe pasar necesariamente por la plataforma .NET... y no tiene por qué ser así. Personalmente, me gusta la plataforma y, de no mediar necesidad en forma de contratos de empresa, prácticamente todos los planes de mi empresa a corto y mediano plazo pasan ya por .NET (esto merece una explicación, pero no ahora). Pero sigue existiendo el desarrollo nativo para el propio Windows, y está, por supuesto, Linux. Otra cosa sería determinar el tamaño de estos mercados, y si son suficientes para mantener vivo un producto comercial de la envergadura de Delphi.
Hay otra trampa más sutil: lo que he dicho antes es que ya no es posible seguir usando sin más la misma estrategia que hizo grande a Delphi en el pasado. Pero una aseveración así se parece mucho a: "es imposible volar con un aparato más pesado que el aire". Puede aparecer un genio y cambiar la historia. Pero mientras no surja un Elegido con ideas frescas que resuciten el espíritu del Delphi de los 90s, los remedios tradicionales no podrán hacer mucho por este enfermo crónico. Y los bandazos y meteduras de pata de la nave nodriza no son buenos para la salud de nadie.
domingo, febrero 19, 2006
The Power of Babel
sábado, febrero 18, 2006
Freya y Frodo
Entre estos idiomas imaginarios, hay dos que destacan: el Quenya, que vendría a ser una especie de Latín élfico, la lengua originaria hablada por estos, y el Sindarin, una evolución posterior de la misma. En el diseño del Quenya hay elementos sacados del castellano y del finés, o suomi (suomen kieli). Tolkien se sentía atraído por la predominancia de las vocales en estos idiomas (pronuncie en voz alta, por ejemplo, Vainamoinen o Ilmarinen, personajes del poema mítico Kalevala, y compare, por ejemplo, con el nombre propio Iluvatar, el Creador en la mitología esbozada en el Silmarillion, o con el nombre genérico Ainur, que corresponde a los primeros seres creados por Iluvatar.
Pero para la historia que ahora relato es más importante el Sindarin. El Sindarin, en el que Tolkien inyectó elementos de otro de sus idiomas preferidos, el galés, es una lengua "gastada". Quiero decir: presenta los mismos fenómenos que se encuentran en los idiomas reales y que explican por el uso de la misma a lo largo de los siglos. Este es un tema fascinante y casi inagotable, y lamento no disponer de tiempo para desarrollarlo.
Cuando empezamos a diseñar Freya, me vino a la mente esta historia sobre el Quenya y el Sindarin, y propuse que el lenguaje que surgiese sobre el papel fuese sometido a un proceso de desgaste, a ver qué salía. ¿Cómo? Escribiendo páginas y páginas de código, detectando los errores de programación y amplificándolos. La mayoría de las meteduras de pata no tendrían demasiado recorrido, pero algunas de ellas se producirían por fallos en el diseño del lenguaje, ya sea por construcciones ambiguas o por restricciones superfluas. En cuanto tuvimos un primer boceto más o menos funcional de la sintaxis de Freya, me lancé a traducir algoritmos desde C y C++.
En la primera propuesta para Freya, se conservaba la idea de unit, y cada unidad se dividía en secciones public y private. Las implementaciones de métodos debían escribirse siempre en una parte private... con lo cual estábamos mezclando dos conceptos diferentes: visibilidad e implementación (mala idea, por supuesto). La técnica del desgaste enseguida dio frutos para este problema. La primera vez que implementé el omnipresente tipo Stack estaba demasiado atento a no cometer errores con la nueva sintaxis. La segunda vez, sin embargo, se me deslizó un error al declarar los campos privados de la clase. En vez de ubicarlos en la misma declaración de la clase, los moví a la sección private:
// Sintaxis ya obsoleta.
unit Stacks;
public
Stack = class
{ ... }
end;
private
Items: array of Integer;
Count: Integer;
{ ... }
end.
La solución final fue la idea de implementar los miembros de una clase en una sección implementation marcada con el nombre de la clase. Parece una vuelta al estilo original de Delphi... pero no lo es: Delphi usa interface/implementation donde Freya pone public/private, por una parte, e implementation por la otra; además, lo que Freya ofrece es implementation for X is. A partir de este simple cambio, recibimos como recompensa unos cuantos beneficios. Para empezar, lo que motivó la idea: la posibilidad de declarar detalles de la implementación en la cláusula de implementación. Con este sistema nos ahorramos repetir el nombre de la clase que se implementa junto a cada método (como sí obligan Delphi y C++). Además, nos evitamos problemas con otros detalles de implementación como la implementación de interfaces por delegación, los constructores estáticos, la implementación explícita de métodos y propiedades de clases...
Soy consciente que es imposible formalizar una técnica de este tipo ("desgastar" un lenguaje). Además, es muy probable que hubiésemos llegado a la misma idea más tarde o más temprano... pero lo que importa es que el uso intensivo de un lenguaje desde las etapas más tempranas del diseño puede acelerar la detección de problemas, inconsistencias, construcciones incómodas, etcétera.
Como decían en la Tierra Media, elen sila lumen omentielvo...
miércoles, febrero 15, 2006
El monstruo en su laberinto
Debo a la conjunción de un espejo y una enciclopedia
el descubrimiento de Uqbar...
J.L. Borges
... y usted se preguntará qué necesidad había de crear otra bitácora digital, habiendo tantas, dedicada aparentemente a comentar noticias sacadas de otras páginas. El autor, además, tiene página propia e incluso mantiene otra bitácora (en inglés) sobre un lenguaje de programación.
Lo que ha ocurrido es que la noticia sobre Borland me proporciona un buen pretexto para explicar algunas ideas ajenas que han llegado hasta mí en estos últimos años, y alguna pequeña idea propia que ha madurado al calor de las primeras. Cada cierto tiempo, mi cabecita entra en un estado de agitación impropio, y al calor de esta ebullición surgen ante mí ideas extrañas, ridículas, y en contados casos, alguna que otra idea útil. Estoy en mitad de una de esas temporadas; si detallase aquí los libros que estoy leyendo ahora mismo, alguien podría sentirse obligado a llamar a una unidad de emergencia psiquiátrica.
Para aliviar un poco la presión mental, abro esta bitácora digital. Espero que se divierta un poco con algunos de los temas que iré presentando en lo sucesivo: memética, física cuántica, cosmología, biología evolutiva, psicología cognitiva... Como simple aficionado que soy, seguramente soltaré unos cuantos disparates... pero esa es la parte buena de este tipo de páginas: siempre podrá intervenir, comentar y exponer su propia opinión. Sólo le pido que no sea excesivamente severo con este diletante.
Total Eclipse of the heart
Cuando Borland comenzó a mostrar signos de no tener muy claro lo que hacía con Delphi, a partir de Delphi 5, a quienes nos quejábamos se nos explicaba con paciencia y con cierta condescendencia que era mejor que callásemos: la "IDE product line" (¡mwahahaaaa!) se podía permitir "lujos" como Delphi gracias al sacrificio abnegado del Hermano Menor, JBuilder. Quienes programábamos en Delphi éramos una turba molesta, ruidosa y tacaña que no sólo nos negábamos a programar en el lenguaje del futuro (en el siglo XXI sólo se programaría en Java, la gente vestiría ajustados trajes plateados y todos nos afeitaríamos la cabeza), sino que para colmo, no éramos rentables. Y quienes decían cosas como éstas no bromeaban...
Uno, que no es precisamente alguien muy ducho en estos temas de los grandes negocios, sospecha que algo tendrían que ver los acuerdos entre Oracle y Borland sobre JBuilder. ¿Alguien recuerda la ventana de presentación de Delphi 5?
Puede que sea el Zeitgeist... pero este estilo (no es soviético, porque el mindundi mira al monitor; en el "realismo socialista" tendríamos al mismo mentecato mirando al horizonte) me recuerda este otro:
Es un poco "Ayn Randesco": héroes con pinta de oficinistas, heroínas adictas al café y al tabaco y con la sobaquera sin defoliar... aunque la imagen de JDeveloper puede interpretarse también como un efrit hippie con coleta. En cualquier caso, un ejemplo de mimetismo, sea o no deliberado.
Volvamos a lo nuestro. Servidor, que tiene genes de profeta, vio venir la debacle cuando recibió el soplo de que la gallina de los huevos de oro había entrado en la menopausia: la "Java IDE product line" había dejado de ser rentable. ¿El culpable? Aquí volvemos al tema del mensaje anterior: Eclipse, un IDE para Java creado, patrocinado, financiado y exaltado principalmente por IBM, ha sido la causa de la ruina de JBuilder. Un proyecto "open source", casualmente...
Naturalmente, es mucho más agradable culpar a Bill Gates, e incluso es políticamente correcto. Pero los verdaderos "malos" de la película son otros, camuflados bajo disfraces altruistas. Y aquí comienza una historia diferente que será contada en otro momento.
[Más información: Pérdidas de Borland en el último trimestre de 2005]
Open Source killed the software star
A partir de tan escaso material, comienzan las especulaciones. Hay muchas y de diverso pelaje. Hay quien dice que Borland ya tiene un posible comprador. No me lo creo. ¿Para qué, entonces, necesita a Bear, Stearns & Co. Inc. para buscar a ese "comprador" que supuestamente conocen? Las teorías sobre las causas de la crisis son más predecibles. Más o menos se reparten así:
- Un 99% culpa a Montgomery Burns... quiero decir, a Microsoft del fracaso comercial de la "IDE product line".
- Un 0.9% culpa al nuevo CEO, Tod Nielsen, ex-empleado de Monty Burns... err... quise decir, Microsoft, de ponerle Borland en bandeja a Gates. Si no le gustan las fracciones, puede sumar esta facción a la anterior, con lo que tenemos que un 99.9% culpa directa o indirectamente a los de Redmont por la catástrofe.
- Un 0.1% no ha logrado aún cerrar la boca. No estaría de más que recordaran guardar antes la lengua en la cavidad bucal...
Mi teoría es muy diferente, como deja ver el título de esta anotación. ¿Alguien recuerda a qué se dedicó Borland después de sacar Delphi 5? Además de organizar ceremonias colectivas en las que los empleados se golpeaban el pecho como los gorilas y rugían "¡somos los mejores!", la mayor parte de los recursos disponibles para la "IDE product line" (cada vez que lea esta frase, imagine que suelto una carcajada a lo Vincent Price...) se concentraron en crear el más mágico, poderoso y pintiparado Entorno de Desarrollo Integrado para el sistema del pingüino. Tengo frente a mí las cajas de Delphi 6 y Delphi 7:
- La caja de Delphi 6 tranquiliza al comprador asegurándole en letras enormes: Kylix compatible. Es decir: "Ha cometido usted una tontería al seguir programando como un idiota para Windows. Pero nosotros, magnánimos y compasivos que somos, le salvamos de las consecuencias de su pecado asegurándole que podrá ejecutar su triste aplicación en el sistema del pingüino cuando reconozca que se ha portado como un insensato".
- La situación cambia radicalmente al salir Delphi 7. Desaparece lo de kylix compatible. Aparece una nueva pegatina plateada: .NET interoperability (un poco mentirosa, por cierto). Para encontrar una referencia al magnánimo y compasivo Kylix hay que leer la letra pequeña de la caja: "...y con el Kylix 3, que viene incluido...".
¿Se ha dado cuenta de que, además del cambio de tono respecto al maravilloso Kylix, cuando aparecer Delphi 7 hay ya tres versiones de este otro producto en el mercado? ¿Qué resultado dio todo este esfuerzo? Positivo, puede que ninguno. Se vendieron muy pocas unidades de Kylix: ¿cree que un programador que no paga un céntimo por su sistema operativo va pagar 3.000 dólares por un entorno de desarrollo, por muy mágico que sea? Para colmo, quienes rompieron la hucha para adquirir el recién estrenado juguete se encontraron de repente con un IDE lento e inestable, y con muchísima menos funcionalidad que su hermano mayor (¡sin COM, para empezar!, es decir, sin WebSnap, cuando WebSnap era la moda, sin DataSnap...).
Lo peor: Borland perdió un tiempo precioso en esta aventura fallida. Retrasó considerablemente el desarrollo del propio Delphi... porque Delphi 7 es Delphi 6 más un par de bibliotecas de componentes de terceros con funcionalidad limitada. Retrasó el desarrollo del compilador para Delphi.NET. Y la necesidad de "hacer caja" instauró una nueva tradición en Borland: sacar sus productos antes de que estos fuesen lo suficientemente estables.
Y hay más causas directas e indirectas, pero sobre ellas escribiré en otro momento.