Al empezar a escribir esta entrada me preguntaba cómo clasificarla. Después del obligado «gugleo» y leer uno de los primeros resultados me quedó claro el porqué una entrada sobre aplicaciones o técnicas para el manejo de datos (entendiendo «manejo» como análisis o algo similar) debe ser clasificado dentro de la categoría 006 de la clasificación Dewey. Hacerlo en la categoría 005 sería apropiado si se hablara de su almacenamiento, pero al tratarse de acciones sobre éstos y el entendimiento resultante queda claro que esto corresponde más a lo que la categoría 006 comprende.

Tanto en Twitter como en muchos foros «pythonicos» es muy común encontrar la promoción de Python como un lenguaje con el que con pocas líneas es posible hacer grandes cosas. «Cómo generar/leer/editar un PDF con Python en tres/pocas/unas cuantas líneas«, «procesando imágenes/audio/video con un pequeño script de Python«, «generando una interfaz web/de IA/lo-que-sea con Python en unas cuantas líneas» y cosas así son las que se leen por los promotores, evangelistas y entusiastas «pythonistas» dando lugar a creer que es un lenguaje moderno, poderoso y compacto. Lo cierto es que Python es un lenguaje viejo (30 años en el negocio de la informática y computación pinta para más que viejo, de hecho). Ciertamente, y nadie lo niega, el lenguaje ofrece un modelo y construcciones muy útiles que permiten echar mano (quiero creer yo) más fácilmente para quienes implementan el intérprete del lenguaje de las facilidades y ventajas que han sido incorporadas en los microprocesadores en la última década (procesamiento vectorizado, procesamiento en paralelo, concurrencia, multi procesamiento, etcétera que ya no está reservado para grandes super computadoras). Pero echar mano de esto no es del todo por el lenguaje mismo (mucho se debe al interés de quienes implementan el intérprete o compilador, y también al que los lenguajes con todavía más edad y diseñados con una visión muy… digamos, muy «von Neumann», pueden verse impedidos por una compatibilidad retroactiva ser actualizados).

Pero aprovechar estas ventajas y facilidades no es ni gratis ni inmediato. A Python le ha tomado 30 años poder evolucionar (y aún así es considerado un lenguaje de procesamiento lento), C y C++ siguen siendo los referentes de velocidad para lenguajes de propósito general, y ninguno de estos tres puede competir con toda la experiencia y optimización que se ha volcado en un buen compilador de Fortran si de cálculos se trata.

Pero, la verdadera potencia de un lenguaje no reside en su velocidad de procesamiento sino en su capacidad para transformar el pensamiento del programador en instrucciones y secuencias de éstas. La velocidad de ejecución, si bien es consecuencia de modelos y características (llamémosle la «filosofía detrás del lenguaje») adoptados por el lenguaje de programación, es una consecuencia de su implementación. Su potencia (hasta cierta medida) bien puede ser también el permitir el crecimiento de su ecosistema mediante paquetes y bibliotecas de funciones, pero hay un límite en ello. Un límite después del cual ya no es posible hablar de la «potencia del lenguaje» y debería hablarse de la «potencia de la comunidad que lo adopta». Es un punto en el que , salvo por la especialización, el lenguaje ya no es distinguible al de un paquete como es el caso de Mathematica o Matlab, y como en su momento lo fue Clipper o dBase. Presumir que en tres líneas (con la importación de uno o más bibliotecas de funciones) se puede hacer algo y anunciarlo como «lo potente que el lenguaje de programación es», incurre en un error y desvío para quien lo lee y así lo cree.

Escribir estas líneas me trajeron a la mente el caso de Clarion, otro lenguaje que fue llegado a llamarlo «de cuarta generación» (que no lo era) y que se promocionaba por poder hacer en una sola linea lo que con otros de sus contemporáneos requería muchas más. Todos sabemos lo que le pasó a los lenguajes de «cuarta generación».