Nico Aragón

Hoy uno de julio se convierte en efectiva la compra de CodeGear, y con ella Delphi, por parte de Embarcadero, del grupo Thoma Cressey Bravo. He hablado por aquí bastante del proceso por el que Borland ha vendido Delphi, desde el anuncio inicial de que querían vender hasta las noticias recientes de que se había llegado a un acuerdo con Embarcadero. A partir de hoy Delphi tiene oficialmente un nuevo dueño. Que sea para bien.

Actualización 23:30: entre las diversas reacciones, veo esta historia de Allen Bauer en que cita al nuevo jefazo, diciendo que Delphi/C++ Builder son parte de los "productos centrales" junto a los de siempre de Embarcadero. También David Intersimone dice que entre los padecimientos para los que tendrán cura está como primer punto "mis profesionales carecen de independencia porque estamos atados a una única plataforma". Delphi en un puesto especial. Única plataforma malo. Suena bien, ¿verdad?

Antonio Castro Snurmacher me avisa de que ha puesto en Ciberdroide su primera novela disponible para descarga gratuita. Xegor es el comienzo de un ambicioso ciclo llamado Éxodo. Conocí a Antonio a finales del 98, cuando coincidimos en Software AG trabajando en el proyecto SIOM para la bolsa de la energía eléctrica española, un proyecto del que guardo buenísimos recuerdos, tanto técnicos como de la gente, de primerísimo nivel. De Antonio puedo atestiguar que tiene sobrada imaginación, una mente analítica, curiosidad inagotable y la palabra fácil necesaria para completar el ciclo.

Hace tres años usaba Linux en casa como sistema habitual. Después, por cosas del trabajo y porque me compré el portátil, lo fui dejando en favor del XP del portátil de forma que sólo he estado usando Linux como servidor y a través de la consola. Ahora estoy cacharreando con algo (ya contaré otro día) que va mejor en Linux y le he metido las nuevas Kubuntus al sobremesa. Digo las nuevas porque hace una semana probé primero la versión "experimental" con KDE 4 y su interfaz "Plasma". Tenía bastantes ganas de ver lo nuevo de KDE. El resultado no pudo ser más decepcionante. Pasé literalmente horas intentando configurar el escritorio a mi gusto. Tengo que aclarar que mis gustos no son muy especiales. No me gusta tener muchos iconos en el escritorio, sólo los imprescindibles: en Windows el de red y Mi PC, en Linux los que corresponden a dispositivos. A veces dejo caer algo en el escritorio, pero lo suelo procesar rápido y llevarlo a otro directorio. Los programas que uso a menudo me gusta que estén en el "inicio rápido" o en un submenú del "menú inicio". Por lo demás me gusta que la barra inferior esté lo más limpia posible. Pues bien, después de buscar en la web, leer documentación e intentar varias cosas, no conseguí que el resultado fuera ni remotamente parecido. Además, el nuevo menú de inicio tuvo la facultad de enfurecerme, hasta cambiarle el nombre a "Plasta" en mi fuero interno. Supongo que se puede hacer todo de otra forma, pero pasadas unas horas, decidí que ya había perdido suficiente tiempo y reinstalé, esta vez la versión "normal" de Kubuntu Hardy, con KDE 3.5.

Hoy he pasado por otro momento de estupor al ver que ha desaparecido el paquete XMMS de Kubuntu 8. Para el que no conozca Linux, XMMS es lo más parecido al WinAmp clásico. Ahí dejo una imagen con la pantalla principal sólo, aunque también tiene ecualizador y lista de reproducción, lo mismito que el WinAmp. XMMS ha sido durante años mi reproductor de MP3 favorito único en Linux. Sé que existe otro programa llamado "Amarok" que también sirve, entre otras cosas, para oír emepetreses. Pero ese programa no me gusta nada. Pero nada nada. Me gusta XMMS. ¿Por qué se ha eliminado el paquete? Parece que en algunas distribuciones piensan que tiene muchos fallos y no está mantenido. En su lugar ofrecen, cómo no, Amarok, o para los cabezotas como yo XMMS2. La única pega de XMMS2 es que es un programa de consola. He estado buscano un frontal gráfico y los que he visto son horrorosos. Otros forks que se hicieron han desaparecido o están en el limbo.

Y sin embargo, sigue existiendo la página de XMMS, el fetén y lo que es más: siguiendo estas instrucciones, se compila XMMS y funciona perfectamente en Kubuntu. El enlace lo encontré como "topic" en el canal de IRC de XMMS en FreeNode. Así que lo de "muchos fallos y no mantenido" como que no.

Es natural que cuando sale una versión nueva de un programa o sistema operativo, junto con las mejoras se cuele alguna que otra peora. Con Windows es incremental. A cada nueva versión tengo que hacer un repaso de opciones tras la instalación para deshacer las peoras introducidas. No todo son peoras, muchas de las molestias que dieron lugar a esta web y su libro correspondiente se fueron arreglando en versiones sucesivas. Pero la sensación subjetiva suele ser la contraria, porque la reacción cuando estropean algo que antes funcionaba es más fuerte y porque la lista de esos ajustes post-instalación crece. A veces es peor que eso. Windows Vista fui directamente incapaz de hacer que funcionase de una forma más o menos decente, así que me volví a XP. Tengo esperanzas de que KDE 4 se arregle. Después de todo, está todavía en las primeras versiones.

Las peoras se pueden clasificar en dos tipos opuestos. Por un lado están las que consisten en añadir elementos a una interfaz sencilla hasta abarrotarla y hacerla impracticable. En esta categoría se podría ubicar la complicación de la interfaz de Delphi después de la versión 7, solucionable con ajustes y las extensiones de Andreas. En el otro grupo estarían las que, quizás por una reacción a una interfaz barroca, eliminan características útiles, quizás llegando al extremo de empezar de nuevo desde cero. Aquí podríamos situar a Plasma. La simplicidad de las interfaces (véase lo que hacen Google o Apple) suele agradecerse, pero no nos dejemos engañar: ¡conseguir la sencillez es complicadísimo!

Paul Graham cuenta hoy que las ciudades lanzan mensajes a las personas ambiciosas que viven en ellas. Lo único que yo he podido oír es el mensaje que Chiclana, la ciudad donde me crié, me dio respecto a mi carrera profesional: "vete". Pero Mr. Graham tiene un oído bastante más fino y nos cuenta que Cambridge (la ciudad americana cerca de Boston y sede de Harvard y el MIT, no la universidad inglesa) le dice "tienes que ser listo", Washington "conoce a gente influyente", el Valle del Silicio "monta una empresa", Nueva York "hazte rico", Los Ángeles "sé famoso" y San Francisco "vive bien". Hay que escoger con cuidado dónde se vive porque aunque Internet es capaz de conectar comunidades dispersas, hay que tener en cuenta que (frase para recordar) "el mundo físico tiene un enorme ancho de banda" :-) y parece que no hay ciudades que te den el mensaje completo de "tienes que ser listo, conocer gente influyente, montar una empresa, hacerte rico y famoso y así vivir mejor", sino que hay que elegir y sobre todo no empezar por el final. Si te vas a San Francisco, te pueden entrar unas ganas terribles de vivir bien y pasar tu vida entre el pub de Zawinski y la playa, haciendo surf o fumando hierba. Así no hay quien se haga rico. Aunque también es verdad que está allí Embarcadero y algo más al sur Scotts Valley, y parece que se las arreglan para trabajar.

El mensaje de fondo viene a ser que el ambiente es muy importante para marcar un estándar de éxito y tener un aliciente para superarse. No creo que en España haya mucho donde elegir para los programadores. Fuera de Madrid, y probablemente Barcelona, es complicado encontrar un trabajo con un sueldo decente, salvo quizás en la administración pública. Y en cualquier caso, creo que no hay excesivo ambiente "físico". He conocido gente bastante buena, pero dispersa. Y lo que dice Graham de ambiente social... pues no parece que nadie piense que te puedes forrar programando, sino más bien siendo jefe. Así que lo más parecido a un "ambiente" sería lo que se encuentra en Internet. Nos quedamos sin ancho de banda.

Desde luego decir "Internet" tampoco es concretar demasiado. El ambiente de las listas especializadas suele ser bastante distinto al de un foro generalista. Se podría decir que los mensajes son opuestos. Las listas suelen girar en torno al trabajo y hay un tono más comercial, mientras que las bitácoras (individuales o colectivas) ofrecen un panorama de aficiones y aspiraciones personales, y hay un ambiente más idealista. A diferencia del mundo exterior, está más conectada la parte personal. Por eso los medios más generales dan la impresión de ser más influyentes. Bueno, supongo que eres más influyente si das la impresión de serlo :-)

Hace un par de días, Carlos García tuvo la amabilidad de incluirme en su blogroll latino de Delphi, que viene a ser una lista de supervivientes con bitácora de la comunidad delfiniana en castellano, con el aliciente de ir sacando una lista de referencias de lo último publicado por cada uno.

La comunidad de Delphi en español se organizó primero (que yo recuerde, tomad esta historia como una aproximación) en el área de Delphi de Fido, en las news es.comp.lenguajes.delphi y en el canal #Delphi de la red de IRC Hispano. Después, de la mano de Emilio Muñoz, vino Club Delphi donde colaboré con la FAQ de Fido y otros artículos traídos de mi página en Geocities, manteniendo los enlaces y sobre todo en la lista de correo, donde había un ambiente familiar y de compañerismo. También hubo un congreso en Valencia donde solté una charla sobre programación web. Con el tiempo la lista de correo se volvió impracticable, con un tráfico inmenso y el ambiente pasó a ser mucho menos hogareño. Me borré, aunque aún colaboré como socio con Emilio, Ian y José Luis Freire en la revista Mundo Delphi, que mantuvimos durante un años con la ayuda de bastantes otros colaboradores.

Después, la comunidad se fragmentó. Club Delphi pasó de lista de correo a foros, lo que solucionó en buena medida el problema del tráfico. Aparecieron varias otras listas de correo como la del Grupo Albor, las de Latium Software y la Delphi Hackers (que mantuve durante unos años) y otras páginas de información se hicieron más conocidas como Trucomanía, las páginas de Ian Marteens y las de Francisco Charte, también autor de libros y asiduo de los foros desde los tiempos de Fido.

Con esa fragmentación vino también un espíritu reivindicativo y descontento de muchos programadores. Se criticaba la comercialización excesiva, sobre todo en comparación con otras herramientas de código abierto. También se habló mucho de la carencia de traducción de Delphi al español.

Pero a fin de cuentas Delphi siempre ha sido una herramienta comercial y ha funcionado sobre todo para Windows. La intentona de Kylix no fue sino una gran decepción. El ambiente de quienes programamos con él es profesional y comercial. Los "mensajes" de la comunidad van en consonancia.

Hacia fuera hay otra consecuencia: Delphi tiene una imagen menos atractiva que las herramientas de código abierto como Java, Python, Ruby o incluso PHP. Como tampoco tiene el respaldo de una gran empresa como Java o .NET, difícilmente vamos a ver subir la fama de Delphi a la altura de otros, ni siquiera en el caso de que la compra por Embarcadero tenga los resultados que nos gustaría. Aunque se repare el daño hecho por la gestión de Borland en los últimos años, me temo que no va a cambiar demasiado esa imagen. A los que lo conozcamos seguirá gustándonos y desde fuera seguirá hablándose del mundo de la programación como si no existiera.

Hoy por hoy Delphi tiene dos desventajas importantes: la falta de una estrategia multiplataforma y la falta de evolución del lenguaje (de esto ya rajaré otro día), y dos ventajas también importantes: el mejor sistema de interfaz gráfica para Windows y una inmensa base de código tanto comercial como de código abierto que se compila nativamente. En la nueva época se podrán arreglar las dos desventajas, que son lo que técnicamente separa a Delphi de Ruby y Python, los lenguajes de moda (en cuanto a que se hable de ellos, aunque no en su uso). Lo que no me atrevo a esperar es que decidan abrir el código del compilador y la VCL, lo que situaría a Delphi en la liga de los grandes y cambiaría por completo los "mensajes" y la comunidad.

Pues eso: hilo en los grupos de noticias y ahí están los enlaces a las notas de prensa. Marco Cantú opina también.

A mí me parece bien. La situación de CodeGear dentro de Borland era insostenible. Embarcadero es una empresa sólida, que gira en torno al desarrollo y que se mueve en un sector muy similar a CodeGear.

Actualización 21 de mayo: añado algunos datos más.

En estos días he estado leyendo algunas reacciones más, la mayoría favorables y todas bastante tranquilas. No es raro porque el proceso desde que se anunció que Borland iba a vender Delphi y compañía ha durado nada menos que dos años. Pondría los enlaces a lo que he escrito, pero no están (de momento) disponibles por los cambios de soft en esta web. El caso es que después de haberse generado ríos de tinta (o de bits) durante tanto tiempo, queda ya un poco fuera de lugar salir con aspavientos.

Si tuviese que destacar un artículo, sería éste de hace algún tiempo, que contiene una curiosa revelación. Parece que Embarcadero ha pasado por una evolución muy parecida a CodeGear. Embarcadero se hizo fuerte vendiendo herramientas para el personal técnico, aunque en su caso eran DBAs en vez de programadores. En cierto momento, ciertos directivos se hicieron con la empresa y la dirigieron a un sector distinto, el de productos caros dirigidos a otros directivos, el equivalente al ALM de Borland. Esto no fue demasiado bien y más tarde fueron comprados por Thoma Cressey Bravo, un conglomerado de capital riesgo que los ha devuelto al rumbo original. Ahora TCB compran también CodeGear a través de Embarcadero y parecen querer hacer lo mismo: devolverla al espíritu original de Borland, que poco se parece a la Borland actual. En fin, que Embarcadero y CodeGear son empresas parecidas, incluso más de lo que inicialmente parecía. Da la impresión de que para empresas fuertemente tecnológicas de tamaño medio es mala cosa cotizar en bolsa. Salen perjudicadas del tipo de organización que imponen los mercados, y el estar pendientes de los resultados trimestrales y los accionistas, en vez de mejorar los productos y escuchar a los clientes.

Pueden resultar una buena pareja además en cuanto a las herramientas para bases de datos. Delphi no es sólo para bases de datos, como algunos piensan. Pero es verdad que destaca en ese campo. Sin embargo, lo que lleva integrado el IDE para gestión de bases de datos es un tanto pobre. No es raro apoyarse en alguna herramienta más completa, como IBExpert, TOAD o el mismo Embarcadero. Está claro que podría apoyarse en la empresa hermana e integrar algo mejor para diseño y administración. Para Embarcadero, Delphi (o JBuilder) también supone un apoyo competitivo frente a herramientas como Oracle Developer.

Una cuestión que continúa siendo una incógnita es la estrategia multiplataforma. Hay muchos que reclaman poder programar para PDAs o teléfonos y cada vez más los que pedimos que se resucite Kylix. En los foros se ha pedido prudencia y paciencia, por lo menos hasta que esté cerrada la operación de compra (dos o tres meses más, por si no hemos esperado bastante) y los nuevos directivos tomen posesión y expresen su visión de futuro.

Se ha hablado mucho también del exiguo precio de compra. Treinta millones de dólares, cuando hace tres años se hablaba de ciento cincuenta. Aquí el problema parece haber sido que Borland pidió demasiado y sobre todo esperó demasiado para la venta. La situación de Borland en Bolsa no ha hecho más que caer y a estas alturas necesitaban desesperadamente el dinero para mantener a flote su negocio actual.

En definitiva, que se confirman las impresiones iniciales: Delphi parece haber ido a parar al mejor sitio dentro de las posibilidades. Pero el tiempo dirá.

En el último petardazo del alojamiento, se perdió todo el contenido de este servidor. Pude recuperar la base de datos de Drupal. Pero no el trabajo manual que había hecho con .htaccess para enlazar con los artículos antiguos, los que escribí con Pebble. Había escrito un programa con Delphi para extraer el contenido del XML de Pebble, pero tengo que hacer otro para meterlos en Drupal y la vagancia me puede. Por lo pronto anteayer estuve restaurando el firewall. Una ventaja de que no me visite nadie es que no tengo que preocuparme demasiado por esas cosas, a pesar por ejemplo del reciente exploit para escalada de privilegios del núcleo. Pero ya era hora. He descubierto que la nueva versión de Virtuozzo ya usa iptables con estado, lo que ha simplificado mucho las cosas. Antes que nada, recuperé el script con estado de mi viejo artículo de iptables:

# Reglas por defecto, salida permitida, entrada o redirección prohibidas.
# Para hacer pruebas en remoto casi mejor permitir la entrada hasta estar
# seguros, no vayamos a quedarnos sin conexión.

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Borra las reglas que haya.

iptables   -F INPUT
iptables   -F FORWARD
iptables   -F OUTPUT
# iptables -F -t nat

# Esta instrucción por ejemplo usa el estado: permite el tráfico en conexiones
# ya iniciadas (el inicio se define más abajo).  Nota: venet0 es la interfaz
# de red que en otra máquina podría ser digamos eth0.
iptables -A INPUT -i venet0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Permitimos todo el tráfico interno dentro de la misma máquina.
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT

# Y finalmente definimos cuándo se permite iniciar una conexión. 
# Incluimos los protocolos ssh (puerto 22), smtp (25), http (80),
# pop3 (110) y https (443)
iptables -A INPUT -p tcp --dport 22   -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 25   -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 80   -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 110  -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 443  -m state --state NEW -j ACCEPT

# La siguiente línea creo que es innecesaria. El panel de Virtuozzo,
# que escucha por https en el puerto 4643, creo que está "antes" de
# nuestro cortafuegos.
iptables -A INPUT -p tcp --dport 4643 -m state --state NEW -j ACCEPT

Esto está muy bien por la brevedad, pero a diferencia del otro script, el que tenía para iptables sin estado, no incluye el envoltorio para meterlo en el arraque con funciones start, stop y restart. Así que estuve buscando cómo funciona ahora en Debian y encontré este artículo. Está casi bien. Vi que después de ejecutarlo, se puede guardar el estado con:

iptables-save > /etc/firewall-rules

De forma que para que se restaure se pueda usar esta línea:

pre-up iptables-restore < /etc/firewall-rules 

Pero a diferencia de lo que pone el artículo, la tuve que poner en el fichero template, no en el fichero interfaces de /etc/network. Salvo por esa pequeña diferencia, todo parece funcionar como debe.

Todo esto se describe en unos pocos minutos. Hacerlo me hizo estar hasta tarde el jueves. Ayer viernes fue un día lleno de emociones, así que caí en la cama como un ladrillo. Ahora queda la parte en que subo los viejos artículos... ya veremos.

En los últimos meses he participado en la traducción de un programa hecho con Delphi. Conté por aquí los problemas del Translation Manager incluido con Delphi hasta el punto de recomendar que no se use.

En esa última historia contaba cómo terminé por crear una herramienta propia que usa el parser de DFM de la VCL para filtrar los ficheros DFM y sustituir las cadenas de acuerdo a un diccionario. El resultado final es un juego de ficheros DFM en catalán e inglés.

La primera idea fue hacer un script que copiase los fuentes del proyecto a otro directorio, machacase sus DFM con los traducidos y compilase la versión en catalán o inglés. Pero finalmente se me ocurrió la manera de ponerlo todo junto y controlar el idioma con un fichero incluido y $define.

En principio parece fácil. Todas las units que tienen un DFM asociado llevan la siguiente línea, generada automáticamente por el IDE:

{$R *.dfm}

La directriz del compilador R se usa para incluir ficheros de recursos. Los DFM originales eran siempre ficheros de recursos (los que suelen tener la extensión *.RES) con la definición del formulario metida en un bloque binario del tipo RC_DATA. A partir de Delphi 5 (creo) existe la posibilidad de guardar los DFM en disco en formato texto, aunque antes también era posible acceder a ese texto con Alt-F12 o a través del portapapeles. Sea como sea, $R sigue sirviendo para incluir el DFM, aunque sea en formato texto. El asterisco representa el nombre del fichero actual, así que *.dfm en unit1.pas se referiría a unit1.dfm.

Primer intento

Lo más sencillo parece hacer un simple condicional. Por una parte tendríamos la enumeración de idiomas:

{$DEFINE CASTELLANO}
{ DEFINE CATALAN}
{ DEFINE INGLES}

Al faltar el signo del dólar, sólo la primera línea es válida. Pero es fácil cambiar el signo de sitio.

Después podemos usar un condicional. Parece lógico usar lo siguiente:

{$IFDEF CASTELLANO}{$R *.dfm}{$ENDIF}
{$IFDEF CATALAN}{$R *.cat}{$ENDIF}
{$IFDEF INGLES}{$R *.eng}{$ENDIF}

Pero no funciona. Al menos Delphi 6 no se traga como DFM un fichero que tenga extensión .CAT. Creo que el error era algo sobre el formato. En cualquier caso se puede arreglar así:

{$IFDEF CASTELLANO}{$R *.dfm}{$ENDIF}
{$IFDEF CATALAN}{$R *.cat.dfm}{$ENDIF}
{$IFDEF INGLES}{$R *.eng.dfm}{$ENDIF}

Bien, esto funciona. Pero es muy poco práctico tener el define de idioma en cada uno de las units con DFM asociado. Nueva idea: poner todo en un fichero incluido y dejar sólo la directiva de inclusión:

{$I IDIOMA.INC}

Donde lógicamente habríamos puesto lo siguiente:

{$DEFINE CASTELLANO}
{ DEFINE CATALAN}
{ DEFINE INGLES}
 
{$IFDEF CASTELLANO}{$R *.dfm}{$ENDIF}
{$IFDEF CATALAN}{$R *.cat.dfm}{$ENDIF}
{$IFDEF INGLES}{$R *.eng.dfm}{$ENDIF}

La peculiaridad

Esa simple línea no funciona. La peculiaridad de los DFM es que el entorno va a su bola buscando la directriz {$R *.dfm} para saber si tiene que asociar el DFM. El entorno no entra en los ficheros incluidos, así que nos quedaríamos sin poder usar el diseñador de formularios.

Nuevo intento. Pongo no uno, sino dos ficheros incluidos así:

{$DEFINE CASTELLANO}
{ DEFINE CATALAN}
{ DEFINE INGLES}

{$IFDEF CASTELLANO}

Aquí en medio queda el {$R *.dfm}

{$ENDIF}
{$IFDEF CATALAN}{$R *.cat}{$ENDIF}
{$IFDEF INGLES}{$R *.eng}{$ENDIF}

En el principal tendríamos algo así:

{$I IDIOMA.INC}{$R *.dfm}{$I IDIOMAFIN.INC}

Por desgracia a Delphi tampoco le sienta bien que se deje un bloque de compilación condicional abierto entre ficheros.

Lo que sí funciona

Supongo que se puede resolver de varias formas. Lo que he puesto es una línea ligeramente más larga que la anterior.

{$I IDIOMA.INC}{$IFDEF CASTELLANO}{$R *.dfm}{$ELSE}{$IDIOMAFIN.INC}{$ENDIF}

El fichero IDIOMA.INC contiene sólo los defines de idiomas:

{$DEFINE CASTELLANO}
{ DEFINE CATALAN}
{ DEFINE INGLES}

Mientras que el segundo incluido lleva esto:

{$IFDEF CATALAN}{$R *.cat}{$ENDIF}
{$IFDEF INGLES}{$R *.eng}{$ENDIF}

A pesar el condicional el IDE siempre va a pillar el fichero *.dfm, que es lo que veremos siempre en tiempo de diseño, mientras que el compilador escogerá el que se decida en idioma.inc.

Finalmente podemos meter todos los DFM de todos los idiomas en el mismo directorio y controlar el idioma de compilación modificando un solo fichero.

Los reyes magos me han dejado como regalo "Cosmos, Guía Ilustrada" de Giles Sparrow. Se trata de un libro tamaño atlas con fotos de objetos celestes y textos explicativos, aunque la verdad es que de momento paso todo el tiempo mirando las fotos, que por cierto son magníficas.

El material de esta guía está actualizado creo que hasta el año recién terminado. Me suena que las imágenes de la sonda que aterrizó en Titán son así de recientes. Al bueno de Plutón ya lo han degradado.

Hace unos días consulté en las news de CodeGear qué opciones hay usando sus herramientas para crear la interfaz de usuario de un programa cuyo "back-end" ha sido escrito en C#. La experiencia ha sido sorprendente por varias razones. No sabía que CodeGear hubiese "congelado" su C#, no sólo como producto independiente, sino también dentro del RAD Studio, en el que no tiene acceso al diseño de formularios. Realmente tampoco esperaba, por eso es bueno preguntar :-) que hubiese buenas opciones para crear la interfaz con Delphi.NET. CodeGear ha desechado Winforms y se ha quedado con el otro toolkit, VCL.NET. La ventaja de éste es que tiene un diseñador de formularios bastante más usable que el de Visual Studio y que las interfaces creadas responden con más agilidad que las construidas con Winforms. En el lado negativo, parece que cualquier librería gráfica no apoyada directamente por Microsoft necesita privilegios especiales para ejecutarse.

Pero si hay algo que me ha sorprendido es la falta de opciones. Hace unos años Microsoft dominaba el mercado de herramientas de programación para escritorio con su Visual Basic "clásico" (quiero decir el que no era .NET) con bastante más usuarios que entornos como Delphi u otros lenguajes de su Visual Studio como el C++. Ahora han dejado de desarrollar ese producto y se vuelcan con .NET donde, sea con VB o con C#, no parece haber opción para crear interfaces de usuario con la misma riqueza que la anterior generación de herramientas. No tengo experiencia directa, corregidme si me equivoco, pero lo que me llega es que el diseñador de formularios es incómodo y los controles son pobres y responden con lentitud. La frase literal ha sido que "parece Java". ¿Es realmente tan malo? ¿Qué han hecho los programadores de VB? ¿Siguen con la versión 6?

Los partidarios de .NET parecen pensar que se arreglará en las próximas versiones, que WPF (que ahora mismo tampoco se encuentra en un estado verdaderamente usable) sustituirá finalmente a Winforms y que el entorno de desarrollo mejorará. Pero es difícil entender por qué se habría de meter Microsoft en semejante berenjenal con vistas al futuro, cuando ya tenía en el presente el dominio, cabreando además a sus programadores y perdiendo una ventaja sobre la competencia.

Si hay un terreno de importancia estratégica en las guerras del software, es el de la programación de interfaces gráficas de usuario. Hay pocas organizaciones que hayan sido capaces de crear un "ecosistema" suficientemente rico y fácil de usar. Los lenguajes emergentes como Ruby o Python suelen tirar más bien por la socorrida interfaz web, ya que para usar Qt o el API de Windows cómodamente es poco menos que imprescindible tener un IDE. A pesar de todos los pesares, Delphi sigue teniendo un algo que no tienen los demás :-)

Hace algún tiempo publiqué esta historia sobre Personal Systems Design, una empresas en la que trabajé al llegar a Madrid, hace ya más de diez años. El fondo del asunto es que, siendo una empresa pequeña, tenía una metodología de trabajo muy superior a empresas mucho más grandes y sonadas en las que trabajé después. Mientras que las empresas grandes se preocupan por la "calidad externa", la del proceso burocrático, PSD buscaba la excelencia en la calidad interna, en hacer programas mejores, con menos fallos, más mantenibles.

Alexander, el artífice de aquel buen hacer, ha tenido el detalle de publicar el manual de estilo de programación de PSD bajo licencia Creative Commons. Me resulta difícil añadir algo que anime a usarlo más que lo que ya escribí en la historia anterior. Seguramente da igual lo que yo diga. No entiendo cómo se pueden dirigir proyectos de software ignorando esta información, pero es lo que ocurre habitualmente. Lo único que puedo decir es que el manual resume en cincuenta páginas la chicha de varios gruesos libros con lo mejor que se ha escrito sobre calidad de código. Así que a quienes sepan apreciarlo: ¡que lo disfrutéis! :-)