Como sabemos, la historia de la informática se caracteriza por una sucesión de diferentes paradigmas. Recordemos que, en los años 30, por un lado, Gödel, Turing, Church, etc. sentaron las bases de la Informática; y, por otro lado, en los años 40 se construyeron los primeros ordenadores (Z1 de Zuse, ENIAC, Mark I de IBM, etc.). Los primeros basados en tubos de vacío, a finales de los 40 aparecieron los ordenadores basados en transistores y a finales de los 50 los circuitos integrados, luego los primeros microprocesadores 1971, y los ordenadores personales en los 80.

Estos ordenadores trajeron los lenguajes de máquina y ensamblador; y más tarde, en los años 60, los primeros lenguajes de programación de alto nivel (FORTRAN, COBOL, etc.). Así, surgió la necesidad de técnicas de programación estructurada (Dijkstra), y de técnicas de diseño y análisis estructurado en los 70, y de metodologías completas en los 80.

El mismo patrón siguió la tecnología orientada a objetos (OO), los lenguajes OO se difundieron en los 80 (C++, Objective-C, Eiffel). En 1990 se empezaron a proponer técnicas de diseño y análisis de OO (UML, Unified Process, RUP, etc.) y surgieron otros lenguajes como Java; y en los 2000 se han adoptado metodologías ágiles para el desarrollo de OO.

En la última década, se difundió un conjunto de tecnologías en torno a DevOps: Infraestructura como Código (ej. Puppet), Integración y Despliegue Continuo (ej. Jenkins), Automatización de Pruebas (ej. Pepino, Jmeter), Contenedores (ej. Docker), Orquestación (ej. Kubernetes) Despliegue (ej. Opctopus, Elastic). Y comenzó una tercera ola en el desarrollo de programas informáticos.

Todos esos cambios exigieron importantes inversiones en la adquisición de conocimientos y plataformas, y en ocasiones provocaron pérdidas económicas por las apuestas en tecnologías o lenguajes que terminaron desapareciendo por falta de madurez o por las presiones del mercado. Por otro lado, las empresas que esperaron demasiado tiempo para incorporar estos avances no pudieron aprovechar la ventaja competitiva ofrecida, lo que incluso llevó en algunos casos a su desaparición.

La historia se repite con la computación cuántica. A principios de los ochenta, Richard Feynman planteó la cuestión de la construcción de un ordenador cuántico para simular nuestro “mundo cuántico”, y Paul Benioff en 1980 y Yuri Manin sentaron las bases teóricas de la computación cuántica. En 1985 David Deutsch propuso la “Computación Cuántica Universal”. Así comenzó la “segunda revolución cuántica”.   En los años 90 se propusieron algunos algoritmos cuánticos: Deutsch y Jozsa, Shor, Grover, etc. En 1995, Juan Ignacio Cirac y Zoller propusieron la construcción de un ordenador cuántico utilizando iones atrapados. Y desde entonces, se han investigado muchas técnicas diferentes para construir cúbits a nivel físico: átomos neutros, superconductores, puntos cuánticos, basados en semiconductores, centros NV, topológicos, fotónicos y de resonancia magnética nuclear.

Con los nuevos ordenadores cuánticos (ya sean simuladores, quantum annealers u ordenadores cuánticos basados en puertas), también están apareciendo nuevos lenguajes de programación cuántica (qGCL, Q Language, QML, Quipper, OpenQASM, Qiskit, Q#, Silq, QIR, etc.), que proponen diferentes formas de crear aplicaciones cuánticas.

El problema que surge, y más en estos momentos de rápida evolución y falta de estandarización en la programación cuántica, es el temor por apostar por una plataforma que no continúe en el futuro. Todo esto lleva a las empresas a frenar la adopción de aplicaciones cuánticas, lo cual es peligroso porque el uso de tecnologías cuánticas puede llevar a un período relativamente importante de aprendizaje y experimentación. Además de no poder aprovechar oportunamente todos los beneficios que ofrece este nuevo paradigma.

Pero ya estamos en la cuarta era del desarrollo de software, por lo que debemos prepararnos para aprovecharla al máximo. El “Manifiesto de Talavera” insta a ocuparse de la producción de software cuántico aplicando los conocimientos y las lecciones aprendidas en el campo de la ingeniería de software. Esto implica aplicar o adaptar los procesos, métodos, técnicas, prácticas y principios de ingeniería de software existentes para el desarrollo de software cuántico (o puede implicar la creación de otros nuevos).

Este ha sido uno de los principales desafíos que hemos enfrentado al crear QPath, como Plataforma de Desarrollo y Ciclo de Vida de Aplicaciones de Software Cuántico. QPath propone un entorno que independiza a los programadores de los detalles específicos de cada plataforma y lenguaje, siguiendo el principio de “escribe una vez, ejecuta en todas partes”. De esta manera, QPath apoya la ejecución de unidades de procesamiento cuántico de forma transparente desde el entorno en el que se ejecutan. Por lo tanto, enmascara las complejidades de las diferentes tecnologías apoyando las transformaciones necesarias y automatizando todo el proceso mediante herramientas eficientes.

Esto permite acelerar la construcción y el despliegue de las aplicaciones cuánticas, abstrayendo sus complejidades técnicas, ya que los programadores pueden centrarse en el dominio del problema o en el modelo de negocio, necesitando sólo el conocimiento funcional requerido para la solución.

Creemos que de esta manera QPath puede contribuir significativamente a la adopción de tecnologías cuánticas y específicamente permitir a las empresas desarrollar y desplegar aplicaciones basadas en estas tecnologías, salvaguardando sus inversiones.