Todos los lenguajes de programación que conozco están escritos, es decir, escritos como longitudes de texto de una forma u otra. Pero me pregunto si hay algún lenguaje de programación donde puedas arrastrar y soltar todo el programa; para obtener un bucle, seleccione este cuadro aquí y arrástrelo a esa sección del "código", y así sucesivamente. Y si no hay uno como este, ¿volaría si se inventara uno?
Personalmente no creo que sea una buena idea, pero me gustaría escuchar lo que piensas.
Muchos equipos han hecho sistemas de programación de arrastrar y soltar.
National Instruments "Labview" es probablemente el más conocido y el mejor.
El problema fundamental con el que se encuentran todos es que no hay una forma conocida de convertir un Flying Code Monkey en un experto programador e ingeniero. Como UN ejemplo, no hay diferencia en un Mono de código volador entre un proceso O (N ^ 2) u O (N ^ 3) y un proceso O (N log N), lo que significa que deben suministrarse con rutinas enlatadas para los algoritmos O (N log N), que pueden ajustarse a la medida en los kludges gráficos rápidos que van a construir.
El segundo problema con el que se encuentran todos es que, cuando proporciona los bloques para fines especiales requeridos por el primer problema, la sobrecarga impuesta al mover los datos entre los bloques comienza a ser costosa. Trabajé con un sistema muy bueno llamado Rippen. Cuando realicé el perfil, para ver dónde nos estaba lastimando en una aplicación de procesamiento de sensores con alto rendimiento requerido, me molestó bastante ver que un 20% de mi tiempo de CPU iba a mover datos. (Ya que estaba haciendo el procesamiento de imágenes LADAR, haciendo una buena parte del procesamiento de punto flotante en cada píxel de una imagen de entrada, el 20% de la CPU era MUCHA sobrecarga de datos).
Probablemente puedas moverte por la parte 2 yendo a un sistema basado en compilador: lo alimentas con tu imagen y se compila en un programa ejecutable altamente optimizado, pero no estoy seguro de que realmente solucione los problemas, y podría dañar la naturaleza interactiva de la herramienta.
Cuando se trata de programación, la entrada de texto supera con creces en términos de información especificada que su parte de contador visual.
Yahoo! Pipes es probablemente un ejemplo perfecto de un lenguaje gráfico del tipo que estás describiendo; Usted arrastra y suelta primitivas (todo, desde las fuentes de datos en las que actúa, hasta los bucles y condicionales) para producir un flujo de información a través del sistema.
Es altamente específico del dominio, pero ese es principalmente el punto; Pipes está centrado en los datos, por lo que la visualización (en lugar de la expresión) es primordial. Del mismo modo, los entornos de tutoriales como Scratch o Sprog! enfatiza la visualización de lo que estás trabajando como una ayuda de aprendizaje; la eficiencia de la entrada de datos es una prioridad mucho menor en ese dominio.
De vez en cuando, a alguien se le ocurre un lenguaje de programación de arrastrar y soltar o una herramienta de diseño que va a "poner fin a la programación como la conocemos" y convertir a todos los que la usan en un programador.
La razón por la que ninguno de ellos ha hecho el trabajo todavía y nos ha dejado a todos fuera del trabajo es que en realidad, no importa cuánta funcionalidad de arrastrar y soltar creas y no importa lo amigable que sea el usuario, el simple hecho. es que la programación es difícil.
Las verdaderas disciplinas de la programación tienen que ver con saber cómo resolver problemas, cómo modelar procesos y organizar datos para poder utilizarlos. Incluso entendiendo lo que es posible con una computadora.
Hay pruebas (si son controvertidas) que sugieren que A algunas personas no se les puede enseñar a pensar de esta manera , lo que me lleva a un par de pensamientos interesantes y relevantes. Para empezar, si no puedes pensar de esta manera, hay muchos programadores, por lo que siempre puedes contratar a alguien para implementar una idea si tienes una y crees que vale la pena pagarla. Si puedes trabajar con la lógica de programación lo suficientemente bien, entonces puedes aprender un lenguaje real en lugar de jugar con un entorno de arrastrar y soltar relativamente simple.
Estoy pensando en la programación general aquí. Lo mismo no se aplica necesariamente en un escenario de tipo DSL más limitado en el que arrastrar y soltar puede ser un proceso realmente útil para los usuarios que son especialistas en ese dominio en lugar de los especialistas en TI.
El mejor sistema de programación de arrastrar y soltar que he visto es para los robots Lego Mindstorms NXT.
Esto te permite hacer algunas cosas bastante sorprendentes, controlando algunas funcionalidades bastante complejas.
Sin embargo, en algún momento se descompone y es necesario volver a otro sistema.
Consulte este artículo: enlace
Es posible, sin embargo, que si esto se mejorara, y en diferentes escenarios se atendieran, la necesidad de esto se reduciría cada vez menos.
La programación de flujo de datos (a.k.a. programación basada en flujo) puede ser una especie de. A pesar de eso, la programación de flujo de datos no está completa.
La programación del flujo de datos es el método de creación de aplicaciones, cuando se ponen instancias de componentes en la escena y se conectan sus puertos, para que formen una red de procesamiento de mensajes. Los componentes se pueden elegir de una biblioteca, tienen puertos de consumo (entrada) y productor (salida), que están listos para conectarse con los puertos de otros componentes.
Este es un buen ejemplo, donde ni siquiera se usa un mouse para crear una aplicación de sintetizador, sino manos desnudas y cubos pequeños: enlace
Los artículos de Wikipedia son un buen punto de inicio: enlace http://en.wikipedia.org/wiki/Dataflow_programming
La generación de sonido es un área típica de la programación de flujo de datos. Hay algunos sistemas de síntesis de código abierto: enlace http://alsamodular.sourceforge.net/
Si tiene Mac, puede tener un Quartz Composer preinstalado de fábrica: enlace
También he creado un sistema DF con un amigo mío, pero no tenemos un editor visual todavía , solo visualizador de scripts.
App Inventor de Google parece ser similar (y créditos Scratch).
Tampoco me gustaría codificar nada grande en mí mismo, pero para enseñar "el pensamiento del programador", Scratch es excelente. Es una programación real, pero con gratificación visual instantánea y los bloques de complemento evitan gran parte del " error de sintaxis "frustración que apaga a los recién llegados (una vista que veo reflejada en este artículo ). Tratar de entusiasmar a los niños pequeños con una línea de comandos de python no lo corta en estos días.
Esto ya existe, aunque posiblemente no en la forma en que está pensando. Dos ejemplos son Simulink y Alice.
Simulink es un medio gráfico para ensamblar simulaciones de sistemas dinámicos. Si bien la mayoría de las construcciones son más complejas de lo que normalmente se consideraría como programación, las cosas para y si todavía pueden construirse gráficamente. Simulink es un poco importante en aplicaciones aeroespaciales, ya que el gobierno y muchas de las grandes empresas hacen sus diseños iniciales en Simulink y luego aplican algún tipo de probador de teoremas al "código" de Simulink.
Alice, es una herramienta de entrenamiento para niños que arrastra y suelta. Permite que los niños se diviertan construyendo historias arrastrando y soltando acciones y objetos en una especie de tablón de historias de programación.
Prograph fue un lenguaje genial que fue todo arrastrar y soltar. Además, Wikipedia tiene un artículo con una buena lista de lenguajes visuales .
Hay bastantes lenguajes de programación visual. Un sistema telefónico que administré para un centro de llamadas grande fue programado usando módulos de arrastrar y soltar. Mi tío desarrolló un sistema Just-In-Time para el diseño de líneas de fabricación que fue completamente de arrastrar y soltar y que fue hace 20 años.
Incluso he jugado un juego de combate de robots en la PS1 que usaba un lenguaje de programación de arrastrar y soltar.
La programación textual se ha ejecutado durante 50 años, pero la ingeniería de software debe moverse hacia el ámbito gráfico para enfrentar el siguiente nivel de complejidad. Por ejemplo, la aparición de muchos procesadores de núcleo y los desafíos de la programación paralela están llevando el modelo de subprocesos a su límite. Francamente, creo que la comunidad de software es simplemente arrogante al pensar que hay algo fundamentalmente diferente y especial en la programación que no sería susceptible de visualización como cualquier otro dominio. Al igual que los operadores telefónicos y muchas otras profesiones, la tecnología de automatización adecuada permitirá a los expertos en dominios colaborar pronto en espacios de simulación ricos de sistemas basados en conocimiento. La industria del software está muy retrasada para un cambio de paradigma.
Lea otras preguntas en las etiquetas programming-languages
