Buena pregunta! Gracias por la solicitud de respuesta. ¡Tan intrigante para pensar! No soy experto en computación cuántica, solo conozco algunos conceptos generales. Mi respuesta puede decepcionar, pero lo intentaré.
Me inclino a pensar que la computación cuántica en las primeras etapas, hay dos áreas donde los beneficios del enredo cuántico serían extremadamente útiles:
- autenticación, los quarks enredados podrían servir como pares de claves privadas / públicas
- sincronización, como en la señalización cuando se realizan procesos concurrentes o determinando la simultaneidad, porque los quarks enredados comunican el estado instantáneamente incluso a grandes distancias.
Para los lenguajes de programación, creo que el problema de la sincronización es más interesante y tiene más aplicaciones.
- ¿Cómo saben los físicos cuánticos que la decoherencia también ocurre cuando no estamos midiendo?
- ¿Cómo explicarías cómo funciona Quantum Computing, utilizando objetos cotidianos como analogía, a un niño de 10 años?
- Cómo trazar las funciones de onda del átomo de hidrógeno
- ¿Puedo comenzar a estudiar mecánica cuántica como estudiante de segundo año?
- ¿Qué piensan los físicos cristianos sobre la teoría de la mecánica cuántica de muchos mundos?
En los días en que el “mundo” para un proceso en ejecución reside solo en un espacio de memoria, la sincronización se puede hacer con semáforos o bloqueos dentro del espacio de memoria. Luego expandimos nuestros procesos a multiprocesadores y subprocesos múltiples, y al procesamiento distribuido en múltiples nodos de cómputo, resolvemos el problema de la simultaneidad evitándolo, porque la simultaneidad absoluta es muy difícil de determinar en diferentes nodos de cómputo, pero podemos construir un protocolo de comunicación entre procesos de modo que aún podamos coordinar el ORDEN de ejecución, como una cola. El modelo de actor permitió justamente eso. Hay una gran explicación de cómo el modelo de actor resuelve ese problema:
Con los quarks cuánticos, la información se transmite casi instantáneamente, por lo que puede llenarse el vacío donde necesitamos estar seguros de la simultaneidad absoluta entre dos procesos remotos. Además, los quarks cuánticos podrían usarse como semáforos o bloqueos en la memoria distribuida o el almacenamiento distribuido.
Sin embargo, no creo que esto signifique que Actor Model se volverá irrelevante en la computación cuántica, sino que creo que se vuelve más útil. Debido a que asegurar la simultaneidad en muchos, muchos nodos es muy difícil, aún dependeríamos de resolver problemas haciendo que muchos nodos resuelvan pequeñas piezas del problema en paralelo y luego usar el Modelo de actor para ordenar y cotejar los resultados. Las técnicas que ya hemos desarrollado para big data como Hadoop y HBase serían muy aplicables. Podríamos incorporar quarks cuánticos en el bloqueo simultáneo de muchos, muchos segmentos de datos que abarcan muchos nodos a la vez para la actualización atómica de una sola transacción. Esto podría significar una versión especializada del lenguaje de base de datos habilitado cuántico (SQL de próxima generación que incorporaría capacidades de MapReduce).
¿Qué cualidades procesarían estos idiomas? No tengo mucha imaginación, así que voy a elegir algunas tecnologías que conozco en este momento que tienen algunas cualidades deseables. Creo que Erlang (y su primo, Elixir) y Elm tienen algunas características importantes. Erlang porque implementa el modelo de actor y es un entorno de programación distribuido muy robusto. Elixir porque sus características de compilación hacen que sea más fácil escribir código (más productivo) que compilará a Erlang byte-code y se ejecutará en Erlang VM. Elm porque es una programación reactiva funcional que transmite múltiples eventos generados por la interacción del usuario en un solo bucle de eventos. Elm también aprovecha muchos de los avances en la sintaxis del compilador y el lenguaje, como Ruby y Elixir, y dio un paso más para ser un lenguaje estáticamente tipado con inferencia, de modo que las declaraciones son opcionales.
MapReduce, Erlang, Elixir y Elm de Hadoop son lenguajes de programación funcional (FP). Creo que FP es más adecuado para la programación paralela distribuida masiva. Las características de Erlang / Elixir, como subprocesos livianos eficientes, alta concurrencia, mecanismos de tolerancia a fallas (árbol de supervisión de procesos) hacen que sea más fácil dividir aplicaciones complicadas grandes en módulos más pequeños, llamados microservicios. Para la computación cuántica, puedo vernos llevando esto un paso más allá en nano o pico servicios, dividiendo nuestras unidades de trabajo computacional en partes más pequeñas.
Algunos pseudocódigo, estilo Elixir:
final_result = data |> chunk_by (fn (data) -> chunk_criteria (data) end)
|> p_run (list_of_bots, fn (x) -> compute (x) end)
|> acumulador (resultado_i, resultado_cumulado_inicial,
fn (resultado_i, resultado_ acumulado) -> puntada (resultado_i, resultado_ acumulado) final)
La declaración anterior dice: tome los datos y póngalos (|> operador) en el motor chunk_by () para segmentar los datos usando chunk_criteria y los datos segmentados resultantes se envían a p_run () que ejecuta la función compute (x) en la list_of_bots, el Los resultados de estas ejecuciones paralelas se acumulan en initial_cumulated_result utilizando la función stitch () para fusionar los resultados que devuelven los resultados en final_result.
Este es un lenguaje de muy alto nivel. La interfaz con los robots cuánticos, que puede escribirse en un ensamblaje de nivel inferior o lenguaje similar a C, está oculta en la función p_run (). La función acumulador () también interactuaría con robots cuánticos para recopilar los resultados.
Pude ver el lenguaje especializado C de nivel inferior para los robots cuánticos que tienen un mecanismo para llevar el sello de sincronización (como el número de ticks) en su estructura de datos interna.
Ok, eso es todo lo que tengo. Déjame saber lo que piensas.
