¿Por qué no hay una poderosa herramienta de programación de diagrama de flujo capaz de producir aplicaciones de trabajo?

Hay muchas herramientas de programación visual muy ambiciosas como la que usted describe, pero rara vez se usan, por la misma razón que los matemáticos usan la notación matemática y no los ábacos: simplemente no son lo suficientemente expresivos.

La gran mayoría de los problemas de programación son muy abstractos y no se pueden representar de manera eficiente en forma visual. Si bien hay casos en los que una herramienta visual tiene algún sentido, como la capa de secuencias de comandos en Unreal Engine, por ejemplo, la mayoría de la programación es muy abstracta y tiene muchos casos y rutas de ejecución.

Por ejemplo, tome QuickSort, el famoso algoritmo de clasificación. Si cree que los diagramas de flujo son generalmente adecuados para resolver problemas de programación, le sugiero que intente dibujar un diagrama de flujo que describa esto:

Creo que sería posible, pero dudo mucho que sea más adecuado que la mayoría de los lenguajes de programación. Y este es solo un algoritmo muy pequeño: en realidad, el software es mucho más grande. Actualmente estoy viendo un fragmento de código que implementa un componente de desplazamiento para la lista en Spotify. Tiene unos cientos de líneas y el código es bastante expresivo. El conjunto de pruebas automatizadas para él prueba más de 100 rutas de ejecución, y todas son necesarias para cubrir todos los casos. Ese componente, en forma de diagrama de flujo, cubriría una pared completa, y eso es solo una parte muy pequeña de una pieza de software completamente funcional.

Recuerdo un concierto anterior que tuve, donde realmente hicieron algo así en la práctica. Estábamos trabajando para una imprenta en su sistema CRM, y alguien había usado una de las grandes impresoras de plotter para imprimir el diagrama completo de la base de datos (esto era solo la base de datos en su forma estática, sin lógica ni nada) y la cosa Tenía dos metros de largo en un diminuto texto con una miríada de flechas. Te hizo querer acurrucarte y morir.

Plug descarado: si te gustan mis divagaciones sobre la programación en Quora, puedes disfrutar de mi programa de YouTube: funfunfunction

En el desarrollo de juegos, hay muchas herramientas poderosas que te permiten expresar la lógica en términos de diagramas de flujo.

La razón por la que no se usan para todo es que una máquina de estado no siempre es la mejor respuesta .

Estos son algunos ejemplos de buenos usos de la lógica del diagrama de flujo :

  • Máquinas de estado de animación
  • Árboles de conversación
  • Máquinas de estado AI

Lo que hace que estos casos de uso sean excelentes es que:

  • Tienen un fuerte concepto de estar en un estado.
  • La lógica se centra en qué estado ir .
  • Tienen un objetivo muy específico que están efectuando. Animación, conversación, etc.
  • Facilitan la publicación de una gran cantidad de contenido diferente en el mismo lugar.

Aquí hay algunas cosas en las que los diagramas de flujo visual son malos :

  • Lectura / escritura en estructuras de datos complejas.
  • Encapsulación
  • Tratar con diferentes niveles de abstracción.
  • Declarando variables con un alcance bien definido.
  • Refactorización
  • Recursividad

El código basado en texto es realmente bueno en todo lo anterior.

Aquí hay un ejemplo de una máquina de estado AI que armé hace un tiempo:

Funcionó, pero al final lo abandoné por un algoritmo basado en el código.

El caso de uso anterior se ajustaba mal a la programación visual porque:

  • El combate en mi juego se basaba en turnos, por lo que no había un concepto sólido acerca de estar en un estado . El flujo del algoritmo se ejecutó en línea recta.
  • Para escribir el algoritmo sobre dónde moverse y qué hacer, necesitaba interactuar con estructuras de datos complejas .
  • La lógica simple fue dolorosa de expresar visualmente (ver la rama izquierda). No importa la lógica más compleja que necesitaba para el algoritmo final.

Eso no quiere decir que no se pueda construir una herramienta mejor que se ajuste mejor a lo que estaba tratando de expresar, pero dudo que sea mejor que C # en un IDE. 🙂

Los editores de programación ya hacen un gran trabajo para evitar errores de sintaxis y eliminar la necesidad de memorizar muchas instrucciones. Y un diagrama de flujo es mucho menos compacto que el equivalente en código escrito, por lo que necesitaría una pantalla más grande, pero incluso entonces creo que un programador experimentado podría comprender más fácilmente un fragmento de código que la parte equivalente de un diagrama de flujo.

No he visto un diagrama de flujo en años. Quizás solo se sigan utilizando para programación de muy bajo nivel (lenguajes de ensamblaje).

La forma más fácil de obtener la respuesta a esta pregunta es intentar escribir ese software. Darle una oportunidad.

Sabrás que vale la pena cuando puedas usar tu software para construir la próxima versión de sí mismo (por ejemplo, iniciarlo).

Mi instinto es que descubrirá la respuesta a su pregunta mucho tiempo antes de llegar a una implementación arrancable.