La mayoría de nosotros aprendimos programación usando lenguajes de programación "textuales" como Basic, C / C ++ y Java. Creo que es más natural y eficiente para los humanos pensar visualmente. La programación visual permite a los desarrolladores escribir programas manipulando elementos gráficos. Supongo que usar programación visual debería mejorar la calidad del código y reducir los errores de programación. Conozco algunos lenguajes visuales, como App Inventor , Scratch y LabView .
¿Por qué no hay lenguajes visuales generales y de propósito general para desarrolladores? ¿Cuáles son las ventajas y desventajas de la programación visual?
programming-languages
Mohammad Al-Turkistany
fuente
fuente
Respuestas:
En general, existe una compensación en el diseño del lenguaje de programación entre facilidad de uso y expresividad (poder). Escribir un programa simple "Hola, mundo" en un lenguaje para principiantes, como Scratch o App Inventor, es generalmente más fácil que escribirlo en un lenguaje de programación de propósito general como Java o C ++, donde puede elegir entre varias secuencias para salida a diferentes conjuntos de caracteres, la oportunidad de cambiar la sintaxis, los tipos dinámicos, etc.
Durante la creación de App Inventor (de la que formé parte), nuestra filosofía de diseño era hacer que la programación sea simple para principiantes. Un ejemplo trivial fue basar nuestros índices de matriz en 1, en lugar de 0, aunque eso hace que los cálculos que los programadores avanzados puedan realizar sean un poco más complejos.
Sin embargo, la forma principal en que los lenguajes de programación visual tienden a diseñarse para principiantes es eliminando la posibilidad de errores de sintaxis al hacer imposible la creación de programas sintácticamente inválidos. Por ejemplo, los idiomas de bloque no le permiten hacer que un valor sea el destino de una declaración de asignación. Esta filosofía tiende a producir gramáticas e idiomas más simples.
Cuando los usuarios comienzan a construir programas más complejos en un lenguaje de bloques, encuentran que arrastrar y soltar bloques es más lento de lo que sería escribir. ¿Prefieres escribir "a * x ^ 2 + b * x + c" o crearlo con bloques?
No se puede hacer justicia a este tema (al menos por mí) en unos pocos párrafos, pero algunas de las razones principales son:
fuente
Los lenguajes visuales tienden a dividirlo en tres grandes categorías:
La ventaja de la programación visual es que obtiene una visión general de alto nivel de la estructura del sistema. Esto lleva al problema inmediato de que cuando se detalla, su código de espagueti realmente se parece a un espagueti . Un componente común de los lenguajes visuales es algún tipo de bloque de código o componente de configuración para el elemento visual. El problema es que el programador necesita dar sentido a los bloques de código desconectados que pueden estar interconectados de manera extraña.
Si bien no hay nada de malo en la programación visual, es posible que simplemente no sea un buen enfoque para la mayoría de las tareas.
fuente
Ha habido numerosos lenguajes de programación visual, como lo mostrarán las siguientes dos bibliografías: vlib.org y oregonstate.edu .
En mi humilde opinión, no han logrado ganar tracción, porque si bien son buenos para los ejemplos de juguetes, no logran administrar los múltiples niveles de abstracción, representación y granularidad que requieren los grandes proyectos. Tendría que mirar un sistema como AutoDesk Revit (un sistema de gestión de la información del edificio utilizado por arquitectos e ingenieros) para ver cuán compleja puede ser la gestión de la información visual.
En lugar de mirar la programación de propósito general, es más probable que la programación visual tenga éxito como herramienta de configuración en dominios especializados.
fuente
El texto es visual.
Usamos todo tipo de señales visuales en nuestro código. Cada uso de espacios en blanco (sangrías, nuevas líneas, líneas en blanco, espaciado intralínea) está dirigido a proporcionar claves visuales para la funcionalidad del código. Utilizamos todo tipo de sintaxis diferente para proporcionar información visual sobre lo que está haciendo el código. Nuestros editores colorean nuestro código para que se destaque.
Las matemáticas son textuales. Hay todo tipo de notación, pero al final todo se reduce básicamente a texto. Lo han estado haciendo durante cientos de años.
Mi punto: la representación textual del código está haciendo uso de las habilidades visuales que tienen los humanos. Probablemente podamos usarlo mejor, pero no abandonando el texto.
fuente
[Para la versión PDF de esta respuesta , las figuras o diagramas son interactivos y dinámicos.]
Elementos netos y anotaciones: un lenguaje de programación visual de uso general
Utilizo gráficos para organizar programas JavaScript ™ que usan la API Acrobat® / JavaScript. Cada objeto gráfico representa un elemento de Petri Net (lugar, transición, entrada o salida) o representa más de un elemento de Petri Net. Cada objeto gráfico es en realidad una anotación del elemento neto correspondiente. Sin embargo, si cada objeto gráfico se asigna a un solo elemento neto, se puede usar para generar el elemento neto. Y si un objeto gráfico se asigna a más de un elemento de red y la asignación está bien definida, entonces también se puede usar para generar los elementos de red. Los elementos estándar de la red de Petri están representados por ciertos tipos de gráficos: un círculo es un lugar, un cuadrado o rectángulo o línea es una transición, una flecha de un círculo a un cuadrado es una entrada y una flecha de un cuadrado a un círculo es un salida. Además,
[Los tipos de anotaciones en una "Red estándar de Petri" se encuentran en la versión PDF de esta respuesta.]
Carl Adam Petri describió la mayoría de estas ideas (incluidos los tipos de anotaciones en una "Red estándar de Petri" en su disertación doctoral (Petri, 1966). También aplicó los elementos netos y las anotaciones a la descripción de varios circuitos lógicos, como la Figura 6)
Beneficios y desafíos
Un lenguaje de programación visual puede ayudar a un programador informático a desarrollar programas informáticos (Menzies, 2002).
Tengo al menos tres razones por las que encuentro útiles las anotaciones y los elementos netos (¿ventajas?).
La primera razón. La lógica del proceso se puede crear un elemento a la vez. Esto significa que una red puede extenderse agregando elementos a la red existente (Petri, 1966). Por ejemplo, un modelo de controlador puede dividirse en componentes internos y externos. El componente interno regula el sistema. El componente externo interactúa con el entorno al aceptar la entrada del entorno. La Figura 1 es un modelo de Petri Net del componente interno. Es posible agregar un modelo de Petri Net del componente externo al modelo de Petri Net del componente interno agregando los lugares y la transición apropiados (Figura 2).
Figura 1 Un modelo de red de Petri de un componente interno de un controlador (Halloway, Krogh y Giua, 1997)
Figura 2 Un modelo de red de Petri de componentes internos y externos de un controlador (Halloway, Krogh y Giua, 1997)
Segunda razón. Los códigos asociados con cada elemento neto pueden provenir de más de un "lenguaje de programación" (Petri, 1973). Pueden provenir de un lenguaje de computadora como JavaScript, COBOL, ADA y un lenguaje ensamblador. Pueden provenir de un lenguaje matemático como los símbolos algebraicos. Pueden provenir de prosa codificada en inglés, alemán, francés, griego, tagalo, chino, etc. Por lo tanto, se puede utilizar como base para la comunicación y la colaboración a lo largo del ciclo de vida de desarrollo de software o sistema; y entre diferentes usuarios, desarrolladores y partes interesadas (Petri, 1973).
Tercera razón Es posible centrarse en ciertos objetos gráficos en la red y escribir el código o las anotaciones lógicas para los objetos gráficos relacionados. Considere un modelo de Petri Net de un juego de cartas en la Figura 3. Si la flecha para la entrada P7 T4 es un gráfico estándar para una entrada en una Red de Lugar / Transición y si m_7 es la marca para el lugar P7, entonces la anotación lógica para actualizar la marca del lugar de entrada es m_7 = m_7-1. Si s_9 ^ - es el estado de la entrada, entonces la anotación lógica para actualizar el estado de la entrada es s_9 ^ - = ((m_7 <1)? Falso: verdadero).
Figura 3 Un modelo de Petri Net de un juego de cartas
Tengo al menos tres razones por las que encuentro desafiante la aplicación de redes de Petri (¿desventajas?)
Si hay demasiados objetos gráficos, sería difícil crear o leer la red. La dificultad puede mitigarse tomando un subconjunto de los gráficos y representándolos con uno, dos o tres símbolos gráficos (Noe, 1973; Petri, 1966). Por ejemplo, si se considera que el modelo Petri Net de un juego de cartas en la Figura 3 tiene demasiados objetos gráficos en el diagrama, es posible combinar algunos de los gráficos y aún mantener suficiente información para mapear el diagrama en un programa de computadora. Considere la Figura 4, un modelo de Petri Net del mismo juego que se encuentra en la Figura 3 con gráficos de alto nivel (Chionglo, 2016a).
Figura 4 Un modelo de Petri Net de un juego de cartas con gráficos de alto nivel (Chionglo, 2016a)
En otro ejemplo, los componentes externos del controlador en la Figura 2 se pueden combinar para crear una representación gráfica más concisa como se muestra en la Figura 5.
Figura 5 Un modelo de red de Petri de un controlador con gráficos de alto nivel para componentes externos
Finalmente, un conjunto de lugares mutuamente excluyentes o un conjunto de transiciones mutuamente excluyentes también pueden representarse utilizando un objeto gráfico de alto nivel (Chionglo, 2015).
Segunda razón. Incluso con gráficos estándar, puede ser difícil dibujar y colocar gráficos, especialmente si se espera que el diagrama final sea fácil de usar o leer. Algunas de las decisiones para hacer un diagrama amigable para el usuario o el lector incluyen: la disposición adecuada de los objetos gráficos, las dimensiones apropiadas del lienzo y las formas, la curvatura de las flechas, el tipo de puntas de flecha, el tamaño y la fuente del texto, y la elección de colores para gráficos y texto.
Tercera razón Es fácil crear anotaciones de elementos netos de manera ordenada porque cada anotación está directa o indirectamente relacionada con un elemento neto. Sin embargo, mostrar cada anotación junto con los gráficos de cada elemento neto puede no ser una buena idea porque podría haber demasiada información presentada en el diagrama. Por ejemplo, considere un diagrama de un modelo de red de Petri de un circuito lógico que incluye referencias a todas las propiedades y anotaciones lógicas (Figura 6). [El modelo original incluía una condición de prueba para el estado de cada salida (figura 31 en la página 78 de (Petri, 1966)); aquí se omitió la condición de prueba porque es equivalente al modelo original para la marca inicial dada. Por lo tanto, cada salida tiene una anotación lógica para calcular la marca del lugar de salida.]
Figura 6 Una red de lugar / transición con anotaciones: basada en la figura 31, página 78, de una traducción al inglés de la disertación de Petri (1966)
Una forma de mitigar este desafío sería identificar los tipos de anotaciones utilizadas en el modelo y definir objetos gráficos que incluyan anotaciones de estos tipos (Petri, 1966). Así, cuando un diagrama de Petri Net se compone de objetos gráficos de las definiciones, la interpretación de estos objetos debe incluir las anotaciones "invisibles". La figura 7 debe interpretarse como una red de Petri estándar (consulte las anotaciones de una red de Petri estándar para obtener las definiciones); por lo tanto, la anotación lógica puede omitirse del diagrama.
Figura 7 Una red de lugares / transición: basada en la figura 31, página 78 de una traducción al inglés de la disertación de Petri (1966)
Otra forma de mitigar este desafío sería utilizar vistas de formulario de las anotaciones para complementar o complementar los diagramas (Chionglo, 2016b; 2014). Las vistas pueden dividirse aún más en vistas más pequeñas, y cada vista puede mostrarse y ocultarse.
Referencias
Chionglo, JF (2016a). Una respuesta a "¿Cómo diseñar un flujo de estado para un juego flashcard react / redux?" En Stack Overflow. Disponible en https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_at_Stack_Overflow .
Chionglo, JF (2016b). Dos vistas de una red de Petri. Disponible en http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf .
Chionglo, JF (2015). Reducir el número de gráficos de elementos netos en un diagrama de red de Petri utilizando gráficos de alto nivel. Disponible en http://www.aespen.ca/AEnswers/WjTpY1429533268 .
Chionglo, JF (2014). Elementos netos y anotaciones para la programación de computadoras: cálculos e interacciones en PDF. Disponible en https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .
Halloway, LE; Krogh, BH y Giua, A. (1997). Una encuesta de los métodos de Petri Net para sistemas controlados de eventos discretos [versión electrónica]. Sistemas dinámicos de eventos discretos: teoría y aplicaciones, vol. 7. Boston: Kluwer Academic Publishers, págs. 151-190.
Menzies, T. (2002). Problemas de evaluación para lenguajes de programación visual. En SK Chang (Ed). Manual de Ingeniería de Software e Ingeniería del Conocimiento, vol. 2 Tecnologías emergentes. World Scientific Publishing co. Pte. Ltd., pp. 93-101.
Noe, JD y Nutt, GJ (1973). "Macro E-Nets para la representación de sistemas paralelos", IEEE Transactions on Computers, vol. C-22, N ° 8, agosto de 1973, págs. 718 - 727.
Petri, CA (1973). Conceptos de teoría de redes. En Fundamentos matemáticos de la informática: Proc. of Symposium and Summer School, High Tatras, del 3 al 8 de septiembre de 1973, páginas 137 - 146. Matemáticas. Inst. del Acad eslovaco. de Ciencias, 1973.
Petri, CA (1966). Comunicación con Automota [trans. CF Greene, Jr.]. Suplemento I al Informe técnico RADC-TR-65-377 (Volumen I). Base de la Fuerza Aérea Griffiss, NY: Centro de Desarrollo Aéreo de Roma, División de Investigación y Tecnología, Comando de Sistemas de la Fuerza Aérea, Base de la Fuerza Aérea Griffiss. Recuperado el 31 de agosto de 2011 de http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf .
fuente
Johne Percival Hackworth :
¿Quizás, los lenguajes de programación visual hasta la fecha han sido demasiado inmaduros? La noción de que las visualizaciones avanzadas no se pueden aplicar a los artefactos de software y que se dejan completamente a la 'imaginación' de cada desarrollador para que desarrollen sus propias imágenes podría ser una suposición falsa. Elevar el nivel de abstracción de manera uniforme y automatizada parece obvio, por lo que no se sacrifica la capacidad de realizar abstracciones de bajo nivel y un alto rendimiento de ejecución. En última instancia, esto podría conducir a una "programación" experta en dominios, no muy diferente de la forma en que las hojas de cálculo automatizan la tarea de los programadores de COBOL para manipular los números. La diferencia principal aquí es reemplazar los números con la manipulación de 'sistemas generales'.
fuente
Puede consultar la Programación sin tecnología de codificación (PWCT)
PWCT es un lenguaje de programación visual de propósito general que permite el desarrollo de sistemas y aplicaciones al generar pasos interactivos en lugar de escribir código.
Este es un buen lugar para comenzar y es de código abierto .
fuente
Una pregunta difícil. La programación visual o basada en el flujo se ha vuelto más utilizada, pero no se usa ampliamente en comparación con todos los lenguajes de programación. Factores significativos son el mantenimiento y la estandarización. El código de la computadora se puede imprimir en las páginas. No siempre es tan claro cómo imprimir un programa visual.
en contraste con la respuesta principal actual, diría que definitivamente no existe una limitación teórica inherente al poder de la programación visual frente a los lenguajes textuales. de hecho, la programación visual puede verse como más fácil de mantener algún día basada en una conceptualización humana más rápida de las muchas capas de abstracción . entonces parece haber un elemento inconfundible de inercia social / cultural / conservadurismo en su aceptación.
los editores visuales son probablemente mucho más complejos en su código, y esto es formidable teniendo en cuenta que incluso los IDE basados en texto pueden ser muy complejos, por ejemplo , Eclipse , tenga en cuenta que hay complementos orientados a la programación visual en algunos IDE, como eciplse, por ejemplo, para la construcción de GUI. La programación visual para la construcción de GUI está bastante extendida ahora.
Me parece que el uso de la programación visual está aumentando en áreas selectas y que a partir de ahora puede volverse más común.
no olvidemos que la programación visual es inherente al diseño de chips EE durante décadas donde no es una abstracción y los (sub) sistemas se presentan en diseños 2D exactamente como se pretendía.
El kit Lego Mindstorms , ahora extendido y con más de una década de antigüedad, siempre ha tenido un software de desarrollo basado en programación visual, ahora simplificado significativamente en muchas versiones.
Aquí hay un interesante artículo reciente que analiza la historia y las perspectivas y sugiere que puede ser más común para la programación basada en la web. La disposición dinámica de controles / widgets en una página es una variante de la programación basada en imágenes.
Otra área clave / emergente donde se usa ampliamente en muchas herramientas es BPM, modelado de procesos de negocio.
Cómo un método de codificación arcano del software bancario de los años 70 podría salvar la cordura de los desarrolladores web en todas partes (Fast Company)
BPM, modelado de procesos de negocio wikipedia
fuente
Supongo que la razón por la cual estas soluciones no son tan populares, porque en la mayoría de los casos pueden ser inmanejables y convertirse en un desastre.
Casi todas las herramientas de programación visual disponibles hoy en día son parte de aplicaciones más grandes y se utilizan para un propósito específico (por ejemplo, Blueprint en UE4).
De todos modos, uno nuevo que encontré recientemente para la programación general es Korduene, que en realidad no es un propósito general, ya que es más para crear aplicaciones de Windows.
fuente
Creo que @Raphael y otros están equivocados cuando dicen que un programa es texto. No lo es Son muchas cosas Le está diciendo a la computadora qué hacer o cómo hacerlo. (programación imperativa, declarativa) La asociación de programación con edición de texto es un dogma histórico y contradictorio. El cual fue creado por las entradas / salidas de texto limitadas de las primeras computadoras. ¡Las personas no son analizadores de texto!
Si bien creo que la gente tiene razón en que un lenguaje totalmente visual (donde haces cualquier cosa visualmente, conectando elementos a través del mouse y demás) no es práctico para un lenguaje de propósito general, creo que todos los lenguajes actuales podrían y deberían moverse a un nivel intermedio nivel. Donde los elementos del lenguaje tienen una representación visual, que se guarda en un archivo de lenguaje binario. El programador no escribiría texto como loco, o viviría bajo el hechizo de líneas y sangría.
Pero inserta elementos a través de la combinación más productiva de teclas de acceso rápido / comandos / elementos de IU. Y solo escribe cadenas y otros datos e identificadores. Esto haría imposible los errores de sintaxis y haría que los lenguajes con seguridad y corrección en mente (por ejemplo: ADA) sean mucho más productivos. Y también haría que otros sean más seguros y con menos errores, haciendo imposibles clases enteras de errores comunes. (Como las que ADA evita al ser engorroso)
Hasta cierto punto, las cosas iban hacia aquí. Por sangría automática y coloración sintáctica. Lamentablemente, nadie se dio cuenta (o se preocupó lo suficiente) de que es el concepto central del "analizador de texto humano" lo que está mal. Los argumentos de emacs vs vim son divertidos porque ambos están equivocados. Son "soluciones" a un problema creado artificialmente.
fuente