Atencion
La versión inicial de esta publicación recibió una gran respuesta en Reddit en la forma de más de 300 comentarios. Después de eso, decidí agregarle una pequeña actualización para responder algunas críticas de los muchos recibidos.
Un lenguaje de programación visual es aquel que permite que un programador cree programas manipulando elementos gráficos en lugar de escribir comandos de texto. Un ejemplo famoso es
Scratch , un lenguaje de programación visual nativo del MIT que se utiliza para educar a los niños. Sus ventajas son que hace que la programación sea más accesible para principiantes y no programadores.
En la década de 1990, hubo un movimiento muy popular para introducir la programación visual en un entorno corporativo utilizando las llamadas herramientas
CASE , donde los sistemas corporativos podían definirse usando
UML y generarse [su código] sin la necesidad de atraer desarrolladores de software capacitados. Esto se debe al concepto de "ida y vuelta", donde el sistema puede modelarse visualmente, el código del programa se generará a partir de los modelos resultantes y cualquier cambio de código puede devolverse al modelo. Desgraciadamente, tales herramientas no han podido cumplir su misión, y la mayoría de los experimentos [sobre su implementación] actualmente están en gran parte abandonados.
Por lo tanto, la programación visual no ha ganado popularidad, excepto en algunas áreas muy limitadas. Esta situación se debe en gran parte a los siguientes conceptos erróneos sobre la programación:
- Los lenguajes de programación de texto confunden lo que es esencialmente un proceso simple.
- La abstracción y el desacoplamiento ( desacoplamiento, reducción de la conectividad ) juegan un pequeño papel periférico en la programación.
- Las herramientas que fueron diseñadas para ayudar a la programación no son importantes.
La primera idea errónea insiste en que el desarrollo de software tiene un umbral alto para la entrada, ya que los lenguajes de programación de texto complican la verdadera naturaleza de la programación. La popularidad de Scratch entre los educadores académicos está jugando junto con este concepto erróneo. La idea es que la programación es bastante simple, y si solo pudiéramos presentarla en un formato gráfico claro, reduciría drásticamente la curva de aprendizaje y el esfuerzo mental necesarios para crear y leer el código del programa.
Supongo que este error se debe a la incapacidad de leer un programa típico escrito en el lenguaje de programación de texto estándar e imaginar cómo se convierte en elementos gráficos a partir de cubos y flechas. Si aún puede imaginar esto, inmediatamente se hará evidente que una sola línea de código a menudo se combina con varios "bloques". Dado que incluso para el programa más simple, la presencia de cientos o dos líneas de código no es inusual, su código se convertirá en cientos o incluso miles de elementos gráficos. Un intento de analizar mentalmente una imagen tan compleja será mucho más difícil que simplemente leer el texto del programa equivalente.
La solución para la mayoría de los lenguajes de programación visual es hacer que los "bloques" sean más complejos para que cada elemento visual sea equivalente a un gran bloque de código de texto. Las herramientas visuales del flujo de trabajo son un obstáculo inmediato.
El problema es que el código aún debe definirse en alguna parte. Por lo tanto, el proceso de codificación [en elementos visuales grandes] se convierte en "propiedades de diálogo de programación". Los elementos visuales en sí representan solo el nivel más alto de movimiento del programa durante la ejecución, y la mayor parte del trabajo ahora se realiza en código de texto estándar oculto en "cubos" visuales. Como resultado, tomamos lo peor de ambos mundos y obtuvimos programación de texto que no es compatible con las herramientas modernas.
Los cuadros de diálogo de propiedades suelen ser entornos de desarrollo no estándar e imponen una elección específica de lenguaje, generalmente un lenguaje de script de algún tipo. Los elementos visuales básicos en sí mismos solo pueden ser creados por programadores experimentados, y pueden entenderse completamente solo leyendo su código básico, por lo que la mayoría de los supuestos beneficios de la presentación visual se pierden aquí.
Existe un desajuste de impedancia entre el "código" visual y el código de texto (un
conjunto de dificultades conceptuales y técnicas ), y el programador tiene que navegar por la interfaz entre ellos, a menudo dedicando más esfuerzo a mejorar la herramienta de programación gráfica en sí misma que a resolver la tarea original [de escribir el programa].
Y ahora llegamos a la segunda idea errónea de que la abstracción y la decuplicación juegan un pequeño papel en la programación. La programación visual se basa en el supuesto de que la mayoría de los programas son secuencias de procedimientos simples, algo similares a un diagrama de flujo. Como regla, la mayoría de los programadores novatos piensan que el software funciona así.
Sin embargo, tan pronto como el programa se convierta en algo más que un ejemplo trivial, su complejidad pronto abrumará al programador novato. A los principiantes les resulta muy difícil hablar sobre una gran base de código de procedimiento y a menudo se estancan en los intentos de crear un software estable y eficiente a gran escala. La principal innovación en los lenguajes de programación fue el intento de controlar la complejidad, generalmente a través de la abstracción, la encapsulación y la conectividad reducida. Todos los sistemas de tipos y construcciones de lenguajes de programación orientados a objetos y funcionales son en realidad solo un intento de tomar el control de la complejidad de estos lenguajes.
La mayoría de los programadores profesionales constantemente abstraen y desacoplan el código. De hecho, la diferencia entre el código bueno y el malo es básicamente cuánto logró el programador hacer esto. Las herramientas de programación visual rara vez tienen mecanismos efectivos para tales cosas, como resultado, el desarrollador "visual" está atrapado en las capacidades disponibles, equivalentes a BASIC de la década de 1970.
El error final es que los programadores visuales supuestamente pueden prescindir de todas las herramientas de soporte de programación que se han desarrollado durante décadas. Eche un vistazo a la larga evolución de los editores de código y los IDE. Por ejemplo, Visual Studio admite una herramienta eficaz de inteligencia que le permite echar un vistazo a las miles de API disponibles solo en la biblioteca de clase base. La falta de un buen control de versiones es otra falla importante en la mayoría de las herramientas de programación visual.
Incluso si guardan su diseño en formato de texto, "diffs" no tienen o casi ningún significado. Es muy difícil culpar (encontrar el compromiso y el responsable de cambiar una línea en particular) en un bloque grande de XML o JSON. Las cosas que no tienen significado para la ejecución funcional de un programa, como la posición y el tamaño de los elementos gráficos, conducen constantemente a cambios en los metadatos, lo que hace que diff sea aún más difícil de analizar.
Los lenguajes de programación de texto han aprendido a separar los bloques estructurales de código en archivos fuente separados, por lo que es fácil combinar un cambio en una parte de un sistema con un cambio en otra. Las herramientas visuales generalmente guardan el resultado de acuerdo con el principio de "un diagrama por archivo", lo que significa que la fusión se vuelve problemática, y aún más difícil si el significado semántico de "diff" es difícil de analizar.
ActualizaciónProbablemente me equivoqué cuando tomé una captura de pantalla de Scratch y la usé como un excelente ejemplo en mi primer párrafo. No soy profesor y no tengo mi propia opinión sobre la efectividad de Scratch como herramienta de aprendizaje. Mucha gente dice que es extremadamente útil en la programación de la enseñanza, especialmente para los niños. Todo lo que ayuda a las personas a ingresar al maravilloso y emocionante mundo de la programación solo debe ser elogiado. Realmente no tenía la intención de criticar específicamente a Scratch ahora, este es solo un ejemplo de un sistema de programación visual, que, como me pareció, la mayoría de mis lectores deberían haber escuchado al menos.
Otro ejemplo de contador proporcionado por Reddit fueron las herramientas de estructura estática, como los diseñadores de UI, los diseñadores de esquemas de bases de datos o los diseñadores de clases. Estoy de acuerdo en que pueden ser muy útiles. Cualquier cosa que ayude a visualizar la estructura de datos o la estructura de escala del programa es una ventaja. Pero nunca son suficientes. Esto se evidencia por el completo fracaso de las herramientas de los años 90, como Power Builder, que se basaron en visualizaciones gráficas para crear un entorno de desarrollo sin la necesidad de trabajar con código.
Sobre el autor
Notas, pensamientos en voz alta, aprendizaje a simple vista, malentendidos, errores, opiniones sin diluir. Soy Mike Hadlow, un desarrollador de predicación. Vivo cerca de Brighton en la costa sur de Inglaterra.
La traducción fue respaldada por EDISON Software, una compañía profesional de desarrollo y prueba de software .