¿Cuál podría ser el próximo paradigma de programación?

Si te refieres al próximo en inventarse, es un juego de perdedores, como preguntar cuál será el mayor avance científico en los próximos diez años: podría ser un LED más barato o podría ser una teletransportación intergaláctica que también cura el cáncer y hace que los blancos sean más blancos. Crear un modelo computacional no es trivial y, me imagino, no intencional.

Por otro lado, si te refieres al paradigma que ha estado presente durante décadas descuidado por una industria que dice “es demasiado lento y nunca se puede compilar de manera eficiente”, los lenguajes basados ​​en reglas (un mejor Prólogo) serían la opción obvia, teniendo ha existido por siempre pero nunca consideró mucho más que un juguete lento. La intención es describir solo el comportamiento y dejar que el tiempo de ejecución del lenguaje descubra cómo hacer que ese comportamiento funcione. He visto que se aplica a datos simples (piense en las gramáticas del lenguaje, que básicamente usan reglas de reemplazo), datos complejos (todos los libros de texto de Prolog tienen pilas y similares representados en un par de reglas de comportamiento) y elementos visuales.

Eso haría que los tres modelos computacionales clásicos, la Máquina Universal de Turing (esencialmente imperativo), el Cálculo Lambda (funcional) y las reglas (gramáticas).

Dataflow también siempre ha estado al acecho en los rincones de la industria, encadenando primitivas en gráficos de control. Pero no creo que se ponga al día hasta que los teclados se conviertan en cosa del pasado, porque los archivos de salida de los sistemas de flujo de datos siempre son muy difíciles de entender a la vista, y eso es difícil de vender para los programadores.

Programación de flujo de datos

Las ideas de flujo de datos vienen en una variedad de formas. Como programación “reactiva” en cosas como Angular.js. Como una parte cada vez más importante de algunos lenguajes funcionales. Vendrá como opciones para configurar redes (un área de gran crecimiento en el Internet de las cosas, donde le contará a los dispositivos cómo comunicarse entre sí y qué necesita diferir a / esclavo a cuál).

Verilog ya se usa para definir chips y con FPGA y hardware personalizado convirtiéndose en un componente más ampliamente considerado en la “pila”, esta forma de pensar también se volverá más popular.

El flujo de datos no es práctico para todos los algoritmos, pero creo que lo veremos cada vez mejor integrado con otros tipos de programación. Quizás a través de interfaces gráficas y preprocesadores en nuestros compiladores que entrelazan el flujo de datos entre dispositivos o incluso módulos virtuales, y algunos componentes más funcionales.

‘Siguiente’ no tiene sentido en este contexto. Existen muchos paradigmas de programación, y es beneficioso tenerlos todos en su caja de herramientas. Para que uno se vuelva repentinamente popular es algo arbitrario: la orientación a objetos se hizo repentinamente popular, en detrimento de todos los que lo estaban haciendo en los años 70 (porque se redujo enormemente al punto en que la gente piensa que Java es un lenguaje orientado a objetos ), a pesar de que era más derrochador de lo razonable en ese momento; ni el mérito ni las circunstancias tienen nada que ver con la popularidad del paradigma, del mismo modo que ni el mérito ni las circunstancias tienen nada que ver con la popularidad de los cortes de pelo o los estilos de jeans.

Algo que aleatoriza la mezcla de conceptos de diseño existentes.
Soy diseñador web y siempre tengo dificultades para crear diseños nuevos / refrescantes. Si hay algo que puede mezclar los diversos aspectos de la cantidad conocida de objetos de diseño en diferentes páginas, sería bueno.
¡Porque tengo la sensación de que siempre creo los mismos diseños con diferentes colores y contenido!

En la informática de alto rendimiento hay un fuerte impulso hacia muchas pequeñas tareas informáticas con alguna noción de un gráfico de dependencia de tareas generado dinámicamente y un planificador en el nodo. En teoría, este es un gran método para absorber todos los flops libres en un nodo que puede tener decenas de miles de núcleos de cómputo. Sin embargo, no estoy seguro de lo que significa la optimización del rendimiento en dicho sistema, ya que perturbar el tiempo de ejecución de cualquier tarea o clase de tareas tendrá efectos difíciles de predecir en el orden de ejecución de la tarea en ejecuciones posteriores. (Para el caso, podríamos tener que renunciar finalmente a la reproducibilidad del rendimiento en dicho sistema).

Hay comunidades que están tratando de “resucitar” el paradigma de programación basado en el flujo.

Si visita el siguiente enlace, puede tener una idea al respecto:

Flowhub | Programación visual de pila completa de igual a igual para sus dedos