¿Por qué Clipper falló al pasar de DOS a Windows?

Clipper fue una vez el rey del mundo empresarial en sistemas DOS. Era rápido, compilaba aplicaciones autónomas y dominaba las bases de datos xBase como nadie más. Sin embargo, cuando llegó la era de Windows, Clipper pareció desaparecer casi por arte de magia.

Ilustración del cambio de Clipper en DOS al ecosistema de Windows.
El cambio histórico de Clipper en DOS hacia el ecosistema de Windows.

El problema no fue que Windows fuera incapaz de ejecutarlo. De hecho, durante bastante tiempo se usó muchísimo en DOS y luego en Windows. El verdadero obstáculo fue que Clipper quedó atrapado en el modelo de programación de DOS justo cuando Microsoft estaba cambiando las reglas del juego.

Hubo varias razones para este fracaso. En primer lugar, Clipper estaba diseñado específicamente para DOS: asumía una pantalla de texto de 80×25, acceso directo a la memoria convencional y una ejecución esencialmente monolítica. Cuando Windows 3.x y posteriormente Windows 95 introdujeron ventanas, mensajes, eventos y multitarea, el lenguaje seguía pensando en un modelo antiguo.

En segundo lugar, Nantucket, la empresa original de Clipper, fue adquirida por Computer Associates en 1992. Para entonces, CA gestionó Clipper más como un producto de su catálogo que como una plataforma que necesitaba reinventarse. Mientras Microsoft empujaba hacia Windows NT y Windows 95, Clipper seguía esencialmente en: DOS → Clipper → DOS.

Un tercer factor fue Visual Basic. Este lenguaje apareció en 1991 y permitió a los programadores crear rápidamente aplicaciones con interfaz gráfica nativa. Un programador podía pasar de comandos simples como `GET nombre` a diseñar formularios visuales, mientras que Clipper seguía luchando por su compatibilidad.

Además, la comunidad xBase sí intentó salvarlo con herramientas como FiveWin, Clip-4-Win y CA-Visual Objects. Sin embargo, el ecosistema se fragmentó. Un programador con una aplicación de 200.000 líneas no podía simplemente recompilar su proyecto en Visual Objects; tendría que modificar código, reemplazar librerías y rehacer partes importantes de la arquitectura.

Esto llevó a un círculo vicioso: menos desarrolladores significaban menos herramientas, lo que resultaba en menos aplicaciones nuevas. Mientras que Microsoft construyó un ecosistema completo con Visual Basic, SQL Server y Office, el mundo empresarial empezaba a moverse hacia arquitecturas cliente-servidor.

Es interesante notar que Clipper no murió inmediatamente. Su descendencia demuestra lo contrario: herramientas como Harbour/xHarbour todavía pueden compilar aplicaciones xBase modernas hoy en día. El problema fue más bien histórico, ya que Clipper perdió porque no consiguió convertirse a tiempo en «el xBase de Windows».

Diagrama comparativo entre la fragmentación de Clipper y el ecosistema dominante de Microsoft.
La fragmentación de las herramientas xBase frente al dominio de Microsoft.

Y hay una ironía bastante bonita ahí: FoxPro sí consiguió hacer esa transición. Fue lo que Clipper podría haber sido si hubiera tenido una migración más coherente hacia GUI y bases de datos.

Finalmente, es importante aclarar una duda común sobre la interfaz. Sí hubo muchísimo software que pasó de DOS a Windows conservando casi intacta su interfaz mediante estrategias de compatibilidad o ejecutándose en ventanas DOS. También existió Visual Basic para DOS (VBDOS), que representó el camino contrario al que se plantea aquí: llevar la filosofía visual hacia DOS, aunque con una vida bastante corta.

En conclusión, técnicamente Clipper no era un lenguaje malo para Windows. Perdió porque la industria decidió que «ser Windows» significaba tener GUI nativa en lugar de simplemente ejecutarse sobre el sistema operativo. Tu intuición es buena: había una tercera vía entre seguir siendo DOS y reescribir toda la interfaz, pero lo que faltó fue que esa vía se convirtiera en una estrategia dominante.