Xbase

Se acaba de convocar la primera edición del Concurso anual de aplicaciones xHarbour, cuyas bases están en la web de xHarbour.com. Sinceramente me parece una excelente idea, porque cosas como estas son las que contribuyen a crear comunidad entre los programadores y a sentir que su herramienta está en la cresta de la ola. Recuerdo los años dorados de los lenguajes xBase, a mediados de los 90, en que los desrrolladores de UltimAde ganaron un par de veces el concurso de programación de la revista DataBased Advisor. Los programadores xBase eramos los reyes del mambo, luego vinieron los años oscuros y desde hace un par de años parece que hay luz al final del tunel.

En los hilos de news de xHarbour y FWH donde se anunció el concurso hubo muchas respuestas, alguna de ellas realmente interesante, como la de Sandro Freire – uno de los desarrolladores de HwGui – o la de TheFull. Si Rafa manda algo de su GUI multiplataforma basada en Gtk+ creo que tenemos un serio candidato a premio.

Jaime y yo vamos a competir con las nuevas versiones de el Puchero y Cuaderno de Bitácora. No se cual será el nivel de los programas que se presenten, pero tenemos claro que no tenemos que envidiar nada a nadie. Haremos campañas para que los lectores de nuestros blogs nos voten, a ver si pillamos alguno de los premios, que falta nos hace.

Esta semana ha habido un post en las news de FWH que me ha llamado poderosamente la atención. Es este post se preguntaba por la incompatibilidad entre xHarbour y versiones de FWH previas a la 2.5 y Walter Negro, componente del equipo de xHarbour al que nunca le agradeceremos las explicaciones que nos dá, aclaraba:

Es verdad, xHarbour es compatible con FWH 2.4 hasta la Beta 1.1 que acaba desalir, pero ya no con el último CVS.

Lo que se hizo en xHarbour ahora, es ser compatible con Harbour y con FWH
2.5, aunque sigue existiendo la posibilidad de recompilarlo para mantener la
compatibilidad con FWH 2.4 Dejan de ser compatibles por la misma razón que lo fué Harbour. Esto es, se pasó de SHORT a LONG el registro que indica la cantidad de referencias que existe sobre un array u objeto.

De momento, la manera de solucionar esta incompatibilidad es esta – GRACIAS WALTER -:

Para poder seguir usando el xHarbour actual con FWH 2.4, hay que restaurar
los archivo hbvmpub.h y hbdefs.h anteriores al cambio.

http://cvs.sourceforge.net/viewcvs.py/xharbour/xharbour/include/hbdefs.h?r1=1.55&r2=1.56

Pero yo creo que el tema no es que cada uno se monte de nuevo xHarbour para mantener la compatibilidad. Como decía TheFull en el mismo hilo, no es cosa de que un compilador sea compatible con una librería, sino al revés. No se en que medida estos cambios afectan a FWH, pero creo que sería un detallazo que FiveTechSoft publicase los parches adecuados para que FWH mantuviera la compatibilidad con xHarbour.

Hasta ahora había usado los meter de CanalFive en mis aplicaciones, que eran a 16 bits. Sin embargo, con la modificación en la clase TBitmap de la versión 2.3 de FW los meter dejaron de funcionar, asi que comencé a usar la clase TMeter de FWH. Miré la clase TProgressBar de FWH pero, no se porqué, tenía en la cabeza que no funcionaba bien. Cuando cayó en mis manos xBackupLite una de las cosas que me llamó la atención era que usaba ProgressBar para indicar la realización de la copia de seguridad. Como el código fuente venía incluido fue fácil ver el comportamiento del control en vivo, tas lo cual me dispuse a usar este control en vez de los clásicos meter. El resultado es este:

El próximo día 10 de Julio tenemos prevista una reunión de programadores xBase en Murcia. Seguramente vendrá José F. Giménez a contarnos cosas de Xailer y seguro que hay alguna novedad más.

Si estás interesado en asistir deja un comentario indicando la manera de contactar contigo.

Estos días Jaime y Rafa han publicado post sobre Xailer, José Alfonso le ha hecho una entrevista a Paco sobre vCode y se respira aire fresco dentro de la comunidad xBase. Desde mi punto de vista Xailer lo tiene complicado pues supone un cambio total de paradigma para los programadores xbase.

Un paradigma, de acuerdo a Thomas Kuhn, es la teoría o idea que es compartida por una comunidad científica y que nadie cuestiona. Ahora mismo está claro que el paradigma para programar en Windows es Fivewin/FivewinHarbour pero existen
anomalías dentro del paradigma que pueden hacer que haya una revolución por parte de la comunidad de programadores y esta decida abandonar el paradigma para abrazar otro. Esto se debe sobre todo – sigo con la teoría de Kuhn – a un sentimiento profundo de los miembros de la comunidad de que el paradigma no es el correcto y que deben buscar otro paraguas donde cobijarse. En las teorías de Kuhn el concepto de comunidad científica como ente social es fundamental y viene definido como un grupo de individuos que comparten un paradigma y que tienen lazos de conocimientos comunes.

Hace poco un amigo me dijo una frase que se me ha quedado grabada y que indica claramente que es uno de los progradores xbase en busca de otro paradigma. La frase fue: ‘Estoy harto de esperar tecnologías que nunca llegarán a xbase‘. Uno que se va. ¿ A donde ? Sólo él lo sabe, pero esa duda trascendental es la que indica que va a buscarse otro paraguas.

Si Xailer, o el entorno que sea, quiere triunfar debe hacerse atractivo para la comunidad, debe crear comunidad, de manera que haga que la comunidad de programadores xbase se replanteen lo bueno del paradigma actual y entren en crisis. ¿ Como se consigue esto ? Pues principalmente dando a conocer su herramienta y ofreciendo motivos para cambiar.

José, Ignacio: ¿ Que tal un blog donde nos tengais al día sobre Xailer ?