Lenguajes de programación visual

35

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?

Mohammad Al-Turkistany
fuente
77
Tienes razón: la gente piensa visualmente. Pero las imágenes de código complejo son imposibles de captar de un vistazo, entonces, ¿dónde está la ventaja? Un buen programador tiene un modelo visual del código en su cabeza sin importar lo que esté en la pantalla. Los lenguajes visuales son, en mi opinión, para las personas que (todavía) no han aprendido a abstraer de la representación textual de un programa. Dicho esto, creo que el código textual tiene que verse bien, por ejemplo, estructuras y claro, para que sea navegable con los ojos.
Raphael
@Raphael, OK, imagina esto, ¿qué pasa si te pido una descripción textual de un rascacielos en lugar de su plano?
Mohammad Al-Turkistany
2
Ciertamente, los lenguajes visuales se emplean, al menos en cierto grado, en los constructores de interfaces de usuario. Incluso se pueden conectar botones, etc. al código subyacente que implementa la funcionalidad sin escribir ningún código (excepto el código subyacente).
Dave Clarke
1
@ MohammadAl-Turkistany: Esa comparación no es muy buena. Primero, los rascacielos se construyen "visualmente", por lo que tiene sentido que sus planes encajen; el software es el texto al final del día, por lo que parece apropiado usar texto como modelo. En segundo lugar, no creo que nadie quiera planos de múltiples rascacielos superpuestos que rompan las leyes de la física; pero así es como se ve el software hoy.
Raphael
@ MohammadAl-Turkistany Creo que esto es demasiado amplio. Su último párrafo contiene 4 preguntas. Esto es demasiado.
uli

Respuestas:

36

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:

  1. Los lenguajes de bloque tienden a estar diseñados para principiantes, por lo que no son tan potentes por diseño.
  2. No hay una buena forma visual de expresar algunos conceptos complejos, como los sistemas de tipos, que se encuentran en los lenguajes de programación de uso general.
  3. Usar bloques es difícil de manejar para programas complejos.
Ellen Spertus
fuente
3
¿Puedes decir que los objetos visuales no se adaptan al progreso del usuario?
Raphael
Buena respuesta. Me gusta la mención de las compensaciones de diseño.
John Percival Hackworth
77
@ Raphael, creo que sí. Esa es una de las razones por las cuales el diseño de circuitos integrados pasó de esquemático (que es un lenguaje gráfico) a HDL y síntesis. Creo que alguien interesado en los lenguajes gráficos debería estudiar los usos del esquema y HDL en el diseño de circuitos y por qué ocurrió el cambio y por qué todavía se prefiere el esquema en algunos casos.
Programador
1
@AProgrammer: Interesante. Suena como "aprender visualmente, dominar la abstracción".
Raphael
Creo que la gente debería intentar combinar lo mejor de ambos mundos. Entonces, para "a x ^ 2 + b x + c", lo escribiría, pero aparecería como bloques (o cualquier cosa visual), y luego podría arrastrarlo o hacer conexiones gráficamente. Creo que es todo un asunto de diseño de interfaz de usuario, por lo que el mejor compromiso es el uso más eficaz de los controles gráficos y el teclado, y la visualización gráfica y textual, y creo que podemos hacerlo mejor que la sintaxis sencilla destacando ..
guillefix
21

¿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?

Los lenguajes visuales tienden a dividirlo en tres grandes categorías:

  1. Herramientas que no son programadores para realizar tareas básicas de automatización. Piensa en Automator en la Mac.
  2. Entornos de aprendizaje donde no es práctico tener muchos tipeos, o donde la estructura del programa que muestra el flujo lógico es importante. Piensa Scratch, Alice, etc.
  3. El problema que se aborda es un problema de flujo de datos, y la solución al problema está bien modelada por algún tipo de flujo de datos entre cajas independientes que imitan el mundo físico. LabView y Ableton me vienen a la mente.

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.

John Percival Hackworth
fuente
Solo pensé en hacerle saber que el autor de la otra respuesta piensa que la suya es buena. :-)
Ellen Spertus
Cuando te refieres a Ableton, ¿te refieres a Max / MSP? Los dos son proyectos separados desarrollados por diferentes organizaciones y Max / MSP, así como su hermano de código abierto PureData, son más complejos y expresivos de lo que su punto 3 les da crédito por IMO.
sol
11

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.

CyberFonic
fuente
8

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.

Winston Ewert
fuente
1
Buena observación, pero su última subcláusula es una afirmación audaz. ¿Por qué crees que los elementos visuales más elaborados que el espacio en blanco y los diferentes símbolos (y tal vez los colores) no pueden ayudar?
Raphael
1
@Raphael, no digo que no podamos usar elementos visuales más elaborados, por eso dije "Probablemente podamos usarlo mejor". Estoy diciendo que no sucederá arrojando texto. Todos los lenguajes de programación "visuales" que he visto comienzan con la suposición de que el texto es malo e intenta eliminarlo, y allí están completamente equivocados.
Winston Ewert
6

[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) 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) 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 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) 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 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 red de lugares / 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) 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 .

John Frederick Chionglo
fuente
2

Johne Percival Hackworth :

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.

¿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'.

Sandy Klausner
fuente
2

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 .

usuario11416
fuente
Para un sitio web sobre un lenguaje de programación visual, ese segundo enlace seguramente es demasiado textual. Ni una sola página con capturas de pantalla. Y el enlace de Wikipedia está roto; El artículo fue eliminado por no notoriedad.
Comodín el
2

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.

vzn
fuente
1

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.

NetInfo
fuente
¿Tiene alguna cita para respaldar su afirmación de que, en la mayoría de los casos, los idiomas visuales se vuelven desordenados e inmanejables?
David Richerby
En realidad, sí, por ejemplo, el gráfico de espagueti, incluso con el software que mencioné anteriormente, el desarrollador mismo tuvo ese problema (he estado siguiendo de cerca el desarrollo de esa aplicación), para respaldar mi punto, mira esto ENLACE .
NetInfo
1

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.

mzso
fuente
1
"¡Las personas no son analizadores de texto!" ¿Qué estás haciendo ahora? Pero, en cualquier caso, esta respuesta parece ser principalmente su opinión personal sobre cuál sería la mejor manera de programar. ¿Hay ejemplos de idiomas o investigaciones que pueda citar que lo lleven más allá del nivel de opinión personal? ¿Qué ventajas ves al almacenar el código fuente en formato binario? Me parece que esto lo pondría a merced de errores en el entorno de desarrollo: al menos cuando las cosas se almacenan como texto, puedo usar un editor de texto diferente si mi favorito no funciona por alguna razón.
David Richerby
@DavidRicherby Naturalmente, no hay ejemplos. Estaba hablando de lo que podría ser. El formato binario se puede adaptar al idioma. Podría brindar un mejor rendimiento y seguridad de datos. "Me parece que esto lo pondría a merced de los errores en el entorno de desarrollo". Ese es siempre el caso. Tendría que estar libre de errores. Al igual que muchos otros softwares.
mzso
Si el formato está estandarizado como debería, podría tener editores diferentes. Pensé que sería más útil si la parte visual también está estandarizada. En cuanto a un programa para almacenar y recuperar datos sin culpa no es un requisito exótico. Muchos software maduros logran esto, con errores pocos y distantes.
mzso
1
Pedí "ejemplos o investigaciones"; Has dicho que no hay ejemplos. Eso deja la investigación. Afirma que un formato binario mejoraría el rendimiento y la seguridad. ¿Cómo? Ya tenemos un formato fuente estandarizado: texto. ¿Por qué usar binario? Un lenguaje de programación visual es más complicado y más especializado que un editor de texto: parece más probable que tenga errores y ya hay editores de texto maduros.
David Richerby
@DavidRicherby Text no es un formato de origen. Es un simple archivo de texto tonto, que almacena texto. Por supuesto, sería más complicado, es solo una cosa simple editar texto, no para programar. Sería más rápido evitando el análisis de texto, la interpretación. Un archivo de texto almacena caracteres, un archivo de idioma contendría los elementos del idioma. (más datos) El lenguaje visual no sería más complicado, sería el mismo en una representación diferente. Sin la desventaja del editor de texto. PD: No sé por qué o cómo esperas ejemplos, busca una idea.
mzso