Lenguajes de programación textual versus gráfico

StackOverflow https://stackoverflow.com/questions/13678

Pregunta

Soy parte de un equipo de robótica de una escuela secundaria y existe cierto debate sobre qué lenguaje usar para programar nuestro robot.Estamos eligiendo entre C (o quizás C++) y LabVIEW.Hay ventajas para cada idioma.

C(++):

  • Ampliamente utilizado
  • Buena preparación para el futuro (la mayoría de los puestos de programación requieren programadores basados ​​en texto).
  • Podemos ampliar nuestro código base C del año pasado.
  • Nos permite comprender mejor qué está haciendo nuestro robot.

LabVIEW

  • Es más fácil visualizar el flujo del programa (bloques y cables, en lugar de líneas de código)
  • Más fácil de enseñar (Supuestamente...)
  • "El futuro de la programación es gráfico". (¿Eso creo?)
  • Más cerca de los antecedentes de Robolab que puedan tener algunos nuevos miembros.
  • No es necesario saber íntimamente lo que está pasando.Simplemente dígale al módulo que encuentre la bola roja, no es necesario saber cómo.

Esta es una decisión muy difícil para nosotros y lo hemos estado debatiendo durante un tiempo.Según las ventajas de cada idioma y la experiencia que tengas, ¿Cuál crees que es la mejor opción? Tenga en cuenta que no necesariamente buscamos pura eficiencia.También esperamos preparar a nuestros programadores para un futuro en la programación.

También:

  • ¿Crees que los lenguajes gráficos como LabVEIW son el futuro de la programación?
  • ¿Es más fácil aprender un lenguaje gráfico que un lenguaje textual? Creo que deberían ser igualmente difíciles de aprender.
  • Dado que estamos parcialmente arraigados en ayudar a las personas a aprender, ¿Cuánto deberíamos confiar en los módulos preescritos y cuánto deberíamos intentar escribir por nuestra cuenta? ("Los buenos programadores escriben buen código, los grandes programadores copian código excelente". ¿Pero no vale la pena ser un buen programador primero?)

¡Gracias por el consejo!

Editar:Me gustaría enfatizar más esta pregunta:El capitán del equipo piensa que LabVIEW es mejor por su facilidad de aprendizaje y enseñanza. ¿Es eso cierto? Creo que C podría enseñarse con la misma facilidad, y las tareas de nivel principiante aún existirían con C.Realmente me gustaría escuchar vuestras opiniones. ¿Hay alguna razón por la que escribir while{} debería ser más difícil que crear un "cuadro while"? ¿No es tan intuitivo que el programa fluya línea por línea, sólo modificado por ifs y bucles, como es intuitivo que el programa fluya a través del cable, sólo modificado por ifs y bucles?

¡Gracias de nuevo!

Editar:Me acabo de dar cuenta de que esto está bajo el tema del "debate del idioma". Espero que esté bien, porque se trata de lo que es mejor para una rama específica de la programación, con ciertos objetivos.Si no es...Lo lamento...

¿Fue útil?

Solución

Antes de mi llegada, nuestro grupo (científicos con doctorado, con poca experiencia en programación) había estado intentando implementar una aplicación de LabVIEW de forma intermitente durante casi un año.El código estaba desordenado, demasiado complejo (frontal y back-end) y, lo más importante, no funcionaba.Soy un programador entusiasta pero nunca había usado LabVIEW.Con un poco de ayuda de un gurú de LabVIEW que podría ayudarme a traducir los paradigmas de programación textual que conocía en conceptos de LabVIEW, fue posible codificar la aplicación en una semana.El punto aquí es que Los conceptos básicos de codificación aún deben aprenderse, el lenguaje, incluso uno como LabVIEW, es simplemente una forma diferente de expresarlos..

LabVIEW es excelente para usar para lo que fue diseñado originalmente.es decir.tomar datos de tarjetas DAQ y mostrarlos en pantalla, quizás con algunas manipulaciones menores en el medio.Sin embargo, la programación algoritmos No es más fácil e incluso sugeriría que es más difícil.Por ejemplo, en la mayoría de los lenguajes procedimentales el orden de ejecución generalmente se sigue línea por línea, utilizando notación pseudomatemática (es decir, y = x*x + x + 1) mientras que LabVIEW implementaría esto usando una serie de VI que no necesariamente se siguen uno del otro (es decir,de izquierda a derecha) en el lienzo.

Además, la programación como carrera es más que conocer los aspectos técnicos de la codificación.Ser capaz de pedir ayuda/buscar respuestas de manera efectiva, escribir código legible y trabajar con código heredado son habilidades clave que son innegablemente más difíciles en un lenguaje gráfico como LabVIEW.

Creo que algunos aspectos de la programación gráfica pueden convertirse en algo común: el uso de sub-VI encarna perfectamente el principio de programación de "caja negra" y también se usa en otras abstracciones del lenguaje como Tuberías de Yahoo y Apple Automator - y tal vez algún lenguaje gráfico futuro revolucione la forma en que programamos, pero LabVIEW en sí no es un cambio de paradigma masivo en el diseño de lenguajes, todavía tenemos while, for, if control de flujo, encasillamiento, programación basada en eventos, incluso objetos.Si el futuro realmente se escribe en LabVIEW, el programador de C++ no tendrá muchos problemas para cruzar.

Como posdata, diría que C/C++ es más adecuado para la robótica, ya que los estudiantes sin duda tendrán que lidiar con sistemas integrados y FPGA en algún momento.El conocimiento de programación de bajo nivel (bits, registros, etc.) sería invaluable para este tipo de cosas.

@mendicante Actualmente LabVIEW se utiliza mucho en la industria, especialmente para sistemas de control.Es poco probable que la NASA lo utilice para sistemas satelitales a bordo, pero el desarrollo de software para sistemas espaciales es un juego de pelota completamente diferente...

Otros consejos

Me encontré con una situación algo similar en el grupo de investigación en el que estoy trabajando actualmente.Es un grupo de biofísica y utilizamos LabVIEW en todas partes para controlar nuestros instrumentos.Eso funciona absolutamente genial:Es fácil crear una interfaz de usuario para controlar todos los aspectos de sus instrumentos, ver su estado y guardar sus datos.

Y ahora tengo que dejar de escribir una perorata de 5 páginas, porque para mí LabVIEW ha sido una pesadilla.En cambio, permítanme intentar resumir algunos pros y contras:

Descargo de responsabilidad No soy un experto en LabVIEW, podría decir cosas sesgadas, desactualizadas o simplemente incorrectas :)

Ventajas de LabVIEW

  • Sí, es fácil de aprender.Muchos doctores de nuestro grupo parecen haber adquirido habilidades suficientes para perfeccionarlas en unas pocas semanas, o incluso menos.
  • Bibliotecas.Este es un punto importante.Tendría que investigar esto cuidadosamente para su propia situación (no sé qué necesita, si existen buenas bibliotecas de LabVIEW para ello o si hay alternativas en otros lenguajes).En mi caso, encontrar, por ejemplo, una biblioteca de gráficos buena y rápida en Python ha sido un problema importante que me ha impedido reescribir algunos de nuestros programas en Python.
  • Es posible que su escuela ya lo tenga instalado y ejecutándose.

Desventajas de LabVIEW

  • es tal vez también fácil de aprender.En cualquier caso, parece que nadie se molesta en aprender las mejores prácticas, por lo que los programas rápidamente se convierten en un desastre total e irreparable.Claro, eso también sucederá con los lenguajes basados ​​en texto si no tienes cuidado, pero en mi opinión es mucho más difícil hacer las cosas bien en LabVIEW.
  • tiende a haber Principales problemas en LabVIEW al encontrar sub-VIs (incluso hasta la versión 8.2, creo).LabVIEW tiene su propia manera de saber dónde encontrar bibliotecas y sub-VI, lo que hace que sea muy fácil romper completamente su software.Esto hace que los proyectos grandes sean una molestia si no tienes a alguien cerca que sepa cómo manejarlos.
  • Hacer que LabVIEW funcione con control de versiones es una molestia.Claro, se puede hacer, pero en cualquier caso me abstendría de usar el VC incorporado.Verificar LVDif para una herramienta de diferencias de LabVIEW, pero ni siquiera piense en fusionar.

(Los dos últimos puntos dificultan el trabajo en equipo en un proyecto.Probablemente eso sea importante en tu caso)

  • Esto es personal, pero encuentro que muchos algoritmos simplemente no funcionan cuando se programan visualmente. Es un desastre.
    • Un ejemplo son las cosas que son estrictamente secuenciales;eso se vuelve engorroso bastante rápido.
    • Es difícil tener una visión general del código.
    • Si usa sub-VI para tareas pequeñas (al igual que es una buena práctica crear funciones que realicen una tarea pequeña y que quepan en una pantalla), no puede simplemente darles nombres, sino que debe dibujar íconos para cada uno. de ellos.Esto se vuelve muy molesto y engorroso en sólo unos minutos, por lo que te sientes muy tentado no para poner cosas en un sub-VI.Es demasiado complicado.Por cierto:Hacer un icono realmente bueno puede llevarle horas a un profesional.Intente crear un ícono único, inmediatamente comprensible y reconocible para cada sub-VI que escriba :)
  • Tendrás un túnel carpiano en una semana.Garantizado.
  • @Brendan:¡escucha Escucha!

Observaciones finales

En cuanto a su pregunta "¿debería escribir mis propios módulos?":No estoy seguro.Depende de tus limitaciones de tiempo.No pierda tiempo reinventando la rueda si no es necesario.Es muy fácil pasar días escribiendo código de bajo nivel y luego darse cuenta de que se le acaba el tiempo.Si eso significa que elige LabVIEW, hágalo.

Si hubiera formas fáciles de combinar LabVIEW y, por ejemplo, C++, me encantaría saberlo:eso puede brindarte lo mejor de ambos mundos, pero dudo que los haya.

Pero asegúrese de que usted y su equipo dediquen tiempo a aprender las mejores prácticas.Mirando el código de cada uno.Aprendiendo unos de otros.Escribir código utilizable y comprensible.¡Y divirtiendome!

Y, por favor, perdónenme por parecer nervioso y quizás algo pedante.Es sólo que LabVIEW ha sido un real pesadilla para mi :)

Creo que la elección de LabVIEW o no se reduce a si quieres aprender a programar en un lenguaje de uso común como una habilidad comercializable, o simplemente quieres hacer cosas.LabVIEW le permite realizar tareas de forma muy rápida y productiva.Como otros han observado, no lo libera mágicamente de tener que entender lo que está haciendo, y es muy posible crear un desastre impío si no lo hace - aunque anecdóticamente, los peores ejemplos de mal estilo de codificación en LabVIEW son generalmente perpetrado por personas que tienen experiencia en un lenguaje de texto y se niegan a adaptarse a cómo funciona LabVIEW porque '¡ya saben programar, maldita sea!'

Eso no quiere decir que la programación en LabVIEW no sea una habilidad comercializable, por supuesto;sólo que no es tan popular como C++.

LabVIEW hace que sea extremadamente fácil gestionar diferentes cosas que suceden en paralelo, lo que bien podría ocurrir en una situación de control de robot.Las condiciones de carrera en el código que deberían ser secuenciales tampoco deberían ser un problema (es decir,si es así, lo estás haciendo mal):Existen técnicas simples para asegurarse de que las cosas sucedan en el orden correcto cuando sea necesario: encadenar subVI usando el cable de error u otros datos, usando notificadores o colas, construyendo una estructura de máquina de estados, incluso usando la estructura de secuencia de LabVIEW si es necesario.Nuevamente, esto es simplemente un caso de tomarse el tiempo para comprender las herramientas disponibles en LabVIEW y cómo funcionan.No creo que la queja sobre tener que crear íconos subVI esté muy bien dirigida;puedes crear muy rápidamente uno que contenga algunas palabras de texto, tal vez con un color de fondo, y eso estará bien para la mayoría de los propósitos.

"¿Son los lenguajes gráficos el camino del futuro?" es una pista falsa basada en una falsa dicotomía.Algunas cosas se adaptan bien a los lenguajes gráficos (código paralelo, por ejemplo);otras cosas se adaptan mucho mejor a los idiomas de texto.No espero que LabVIEW y la programación gráfica desaparezcan o se apoderen del mundo.

Por cierto, me sorprendería mucho que la NASA no Utilice LabVIEW en el programa espacial.Alguien describió recientemente en la lista de correo de Info-LabVIEW cómo habían usado LabVIEW para desarrollar y probar el control de circuito cerrado de superficies de vuelo accionadas por motores eléctricos en el Boeing 787, y dio la impresión de que LabVIEW se usó ampliamente en el desarrollo del avión.También se utiliza para el control en tiempo real en el ¡Gran Colisionador de Hadrones!

El lugar más activo actualmente para obtener más información y ayuda con LabVIEW, además del sitio y los foros de National Instruments, parece ser LAVA.

Esto no responde directamente a su pregunta, pero es posible que desee considerar una tercera opción de mezclar en un idioma interpretado. lua, por ejemplo, es ya usado en el campo de la robótica.Es rápido, liviano y se puede configurar para ejecutarse con números de punto fijo en lugar de números de punto flotante, ya que la mayoría de los microcontroladores no tienen una FPU. Adelante es otra alternativa con uso similar.

Debería ser bastante fácil escribir una capa de interfaz delgada en C y luego dejar que los estudiantes se relajen con guiones interpretados.Incluso podría configurarlo para permitir que el código se cargue dinámicamente sin tener que volver a compilar ni actualizar un chip.Esto debería reducir el ciclo de iteración y permitir a los estudiantes aprender mejor al ver los resultados más rápidamente.

soy parcial contra utilizando herramientas visuales como LabVIEW.Siempre encuentro algo que no funciona o no funcionará como yo quiero.Por eso prefiero el control absoluto que se obtiene con el código textual.

La otra fortaleza de LabVIEW (además de las bibliotecas) es concurrencia.Es un lenguaje de flujo de datos, lo que significa que el tiempo de ejecución puede manejar la concurrencia por usted.Entonces, si está haciendo algo altamente concurrente y no quiere tener que realizar una sincronización tradicional, LabVIEW puede ayudarlo.

El futuro no pertenece a los lenguajes gráficos tal como están hoy.Pertenece a quien pueda idear una representación del flujo de datos (u otro tipo de programación compatible con la concurrencia) que sea tan sencilla como lo es el enfoque gráfico, pero que también sea analizable mediante las propias herramientas del programador.

Hay un estudio publicado sobre el tema organizado por National Instruments:

Un estudio de gráficos vs.Programación textual para la enseñanza de DSP

Analiza específicamente LabVIEW versus MATLAB (a diferencia de C).

Creo que los lenguajes gráficos siempre tendrán una expresividad limitada en comparación con los textuales.Compare intentar comunicarse mediante símbolos visuales (por ejemplo, REBUS o lenguaje de señas) con comunicarse mediante palabras.

Para tareas simples, usar un lenguaje gráfico suele ser más fácil, pero para una lógica más compleja, encuentro que los lenguajes gráficos se interponen.

Otro debate implícito en este argumento, sin embargo, es el de la programación declarativa versus la programación declarativa.imperativo.El declarativo suele ser mejor para cualquier cosa en la que realmente no se necesita un control detallado sobre cómo se hace algo.Tú poder use C++ de forma declarativa, pero necesitaría más trabajo inicial para hacerlo así, mientras que LABView está diseñado como un lenguaje declarativo.

Una imagen vale más que mil palabras, pero si una imagen representa mil palabras que no necesitas y no puedes cambiarlas, entonces en ese caso una imagen no vale nada.Mientras que puedes crear miles de imágenes usando palabras, especificando cada detalle e incluso dirigiendo la atención del espectador de manera explícita.

LabVIEW le permite comenzar rápidamente y (como ya han dicho otros) tiene una enorme biblioteca de código para realizar diversas cosas relacionadas con pruebas, mediciones y control.

Sin embargo, la mayor desventaja de LabVIEW es que se pierden todas las herramientas que los programadores escriben por sí mismos.

Su código se almacena como VI.Estos son archivos binarios opacos.Esto significa que su código realmente no es suyo, es de LabVIEW.No puede escribir su propio analizador, no puede escribir un generador de código, no puede realizar cambios automatizados mediante macros o scripts.

Este apesta cuando tienes una aplicación 5000 VI que necesita algunos ajustes menores aplicados universalmente.Su solo La opción es revisar cada VI manualmente, y que Dios te ayude si te pierdes un cambio en un VI en alguna esquina.

Y sí, dado que es binario, no puedes hacer diferencias/fusiones/parches como puedes hacerlo con los lenguajes textuales.De hecho, esto hace que trabajar con más de una versión del código sea una horrible pesadilla de mantenibilidad.

Por supuesto, use LabVIEW si está haciendo algo simple, necesita crear un prototipo o no planea mantener su código.

Si desea realizar una programación real y mantenible, utilice un lenguaje textual.Puede que seas más lento al empezar, pero serás más rápido a largo plazo.

(Ah, y si necesita bibliotecas DAQ, NI también tiene versiones C++ y .Net).

Mi primera publicación aquí :) sea amable...

Provengo de una experiencia integrada en la industria automotriz y ahora estoy en la industria de defensa.Puedo decirle por experiencia que C/C++ y LabVIEW son realmente bestias diferentes con diferentes propósitos en mente.C/C++ siempre se usó para el trabajo integrado en microcontroladores porque era compacto y los compiladores/herramientas eran fáciles de conseguir.Por otro lado, se utilizó LabVIEW para controlar el sistema de prueba (junto con el banco de pruebas como secuenciador).La mayoría de los equipos de prueba que utilizamos eran de NI, por lo que LabVIEW proporcionó un entorno donde teníamos las herramientas y los controladores necesarios para el trabajo, junto con el soporte que queríamos.

En términos de facilidad de aprendizaje, existen muchos recursos para C/C++ y muchos sitios web que exponen consideraciones de diseño y algoritmos de ejemplo sobre prácticamente cualquier cosa que busque y esté disponible gratuitamente.Para LabVIEW, la comunidad de usuarios probablemente no sea tan diversa como C/C++, y requiere un poco más de esfuerzo inspeccionar y comparar el código de ejemplo (debe tener la versión correcta de LabVIEW, etc.)...Encontré que LabVIEW es bastante fácil de aprender y aprender, pero hay algunas molestias, como algunos han mencionado aquí, que tienen que ver con el paralelismo y varias otras cosas que requieren un poco de experiencia antes de que te des cuenta de ellas.

¿Entonces la conclusión después de todo eso?Yo diría que vale la pena aprender AMBOS lenguajes porque realmente representan dos estilos diferentes de programación y ciertamente vale la pena ser consciente y competente en ambos.

Dios mío, la respuesta es muy simple.Usar Vista de laboratorio.

He programado sistemas integrados durante 10 años y puedo decir que sin al menos un par de meses de infraestructura (¡mucha infraestructura!), no serás tan productivo como el día 1 con Vista de laboratorio.

Si está diseñando un robot para venderlo y utilizarlo en el ejército, siga adelante y comience con C: es una buena decisión.

En caso contrario, utiliza el sistema que te permita probar la mayor variedad en el menor tiempo.Eso es Vista de laboratorio.

Creo que los lenguajes gráficos podrían ser el lenguaje del futuro...para todos aquellos desarrolladores ad hoc de MS Access que existen.Siempre habrá un lugar para los codificadores puramente textuales.

Personalmente, tengo que preguntar cuál es la verdadera diversión de construir un robot si ya está hecho por ti.¿Si simplemente colocas un módulo de 'encontrar la bola roja' allí y lo ves funcionar?¿Qué sentimiento de orgullo tendrás por tu logro?Personalmente, no tendría mucho.Además, ¿qué le enseñará sobre codificación o sobre el aspecto (muy importante) de la interfaz de software/hardware que es fundamental en robótica?

No pretendo ser un experto en la materia, pero pregúntate una cosa:¿Crees que la NASA utilizó LabVIEW para codificar los Mars Rovers?¿Crees que alguien realmente destacado en robótica está utilizando LabView?

Realmente, si me preguntas, lo único para lo que te preparará el uso de cosas sencillas como LabVIEW para construir esto es para ser un constructor de robots de jardín y nada más.Si desea algo que le brinde algo más parecido a una experiencia en la industria, cree su propio sistema tipo 'LabVIEW'.Cree su propio módulo para encontrar la pelota o su propio módulo para "seguir la línea".Será mucho más difícil, pero también será mucho más divertido.:D

Me encanta LabVIEW.Lo recomendaría mucho, especialmente si otros recuerdan haber usado algo similar.A los programadores normales les lleva un tiempo acostumbrarse, pero los resultados son mucho mejores si ya sabes programar.

C/C++ equivale a gestionar tu propia memoria.Estarás nadando en enlaces de memoria y preocupándote por ellos.Elija LabVIEW y asegúrese de leer la documentación que viene con LabVIEW y esté atento a las condiciones de carrera.

Aprender un idioma es fácil.Aprender a programar no lo es.Esto no cambia incluso si es un lenguaje gráfico.La ventaja de los lenguajes gráficos es que es más fácil visualizar lo que hará el código en lugar de quedarse sentado y descifrar un montón de texto.

Lo importante no es el lenguaje sino los conceptos de programación.No debería importar en qué idioma aprendas a programar, porque con un poco de esfuerzo deberías poder programar bien en cualquier idioma.Los idiomas van y vienen.

Descargo de responsabilidad:No he presenciado LabVIEW, pero he usado algunos otros lenguajes gráficos, incluidos WebMethods Flow y Modeller, lenguajes de simulación dinámica en la universidad y, ejem, Scratch del MIT :).

Mi experiencia es que los lenguajes gráficos pueden hacer un buen trabajo en la parte de "plomería" de la programación, pero los que he usado activamente obstaculizan la algorítmica.Si sus algoritmos son muy simples, podría estar bien.

Por otro lado, tampoco creo que C++ sea bueno para tu situación.Pasará más tiempo rastreando problemas de administración de memoria y puntero que en un trabajo útil.

Si su robot puede controlarse mediante un lenguaje de programación (Python, Ruby, Perl, lo que sea), creo que sería una opción mucho mejor.

Luego están las opciones híbridas:

Si no hay una opción de secuencias de comandos para su robot y tiene un experto en C++ en su equipo, considere pedirle a ese experto que escriba enlaces para asignar su biblioteca de C++ a un lenguaje de secuencias de comandos.Esto permitiría a personas con otras especialidades programar el robot más fácilmente.Las encuadernaciones serían un buen regalo para la comunidad.

Si LabVIEW lo permite, utilice su lenguaje gráfico para unir módulos escritos en un lenguaje textual.

Estás en la escuela secundaria.¿Cuánto tiempo tienes para trabajar en este programa?¿Cuantas personas hay en tu grupo?¿Ya conocen C++ o LabView?

Por tu pregunta, veo que sabes C++ y la mayoría del grupo no.También sospecho que el líder del grupo es lo suficientemente perspicaz como para darse cuenta de que algunos miembros del equipo pueden sentirse intimidados por un lenguaje de programación basado en texto.Esto es aceptable, estás en la escuela secundaria y estas personas son normas.Siento que los estudiantes normales de secundaria podrán entender LabView de manera más intuitiva que C++.Supongo que la mayoría de los estudiantes de secundaria, como la población en general, le temen a una línea de comando.Para ti la diferencia es mucho menor, pero para ellos es el día y la noche.

Tiene razón en que se pueden aplicar los mismos conceptos a LabView que a C++.Cada uno tiene sus fortalezas y debilidades.La clave es seleccionar la herramienta adecuada para el trabajo.LabView fue diseñado para este tipo de aplicación.C++ es mucho más genérico y puede aplicarse a muchos otros tipos de problemas.

Voy a recomendar LabView.Con el hardware adecuado, puede estar listo y funcionando casi desde el primer momento.Tu equipo puede dedicar más tiempo conseguir que el robot haga lo que quieras, que es lo que debería ser el foco de esta actividad.

Los lenguajes gráficos no son el futuro de la programación;han sido una de las opciones disponibles, creadas para resolver cierto tipo de problemas, durante muchos años.El futuro de la programación es una capa tras otra de abstracción alejada del código de máquina.En el futuro, nos preguntaremos por qué perdimos todo este tiempo programando "semántica" una y otra vez.

¿Cuánto deberíamos confiar en los módulos preescritos y cuánto deberíamos intentar escribir por nuestra cuenta?No deberías perder el tiempo reinventando la rueda.Si hay controladores de dispositivos disponibles en Labview, utilícelos.Puedes aprender mucho copiando código que tenga una función similar y adaptándolo a tus necesidades: podrás ver cómo otras personas resolvieron problemas similares y tendrás que interpretar su solución antes de poder aplicarla adecuadamente a tu problema.Si copia el código a ciegas, las posibilidades de que funcione son escasas.Tienes que ser bueno, incluso si copias código.

¡Toda la suerte!

Le sugeriría que use LabVIEW, ya que puede comenzar a hacer que el robot haga lo que desea de manera más rápida y sencilla.LabVIEW ha sido diseñado con esta mente.Por supuesto, C(++) son excelentes lenguajes, pero LabVIEW hace lo que se supone que debe hacer mejor que cualquier otra cosa.La gente puede escribir software realmente bueno en LabVIEW, ya que proporciona un amplio alcance y soporte para ello.

Hay una gran cosa que encontré negativa al usar LabVIEW para mis aplicaciones:Organizar la complejidad del diseño.Como físico, encuentro que Labview es excelente para la creación de prototipos, el control de instrumentos y el análisis matemático.No existe ningún idioma en el que se obtenga un resultado mejor y más rápido que en LabVIEW.Utilizo LabView desde 1997.Desde 2005 cambié completamente al marco .NET, ya que es más fácil de diseñar y mantener.

En LabVIEW se debe dibujar una estructura simple 'si' y utiliza mucho espacio en su diseño gráfico.Me acabo de enterar de que muchas de nuestras aplicaciones comerciales eran difíciles de mantener.Cuanto más compleja se volvía la aplicación, más difícil era de leer.

Ahora uso idiomas de texto y soy mucho mejor manteniendo todo.Si comparara C++ con LabVIEW, usaría LabVIEW, pero en comparación con C# no gana.

Como siempre, depende.

Utilizo LabVIEW desde hace unos 20 años y realicé una gran variedad de trabajos, desde DAQ simple hasta visualización muy compleja, desde controles de dispositivos hasta secuenciadores de prueba.Si no fuera lo suficientemente bueno, seguramente habría cambiado.Dicho esto, comencé a codificar Fortran con tarjetas perforadas y usé una gran cantidad de lenguajes de programación en 'máquinas' de 8 bits, comenzando con las basadas en Z80.Los lenguajes iban desde Assembler hasta BASIC, desde Turbo-Pascal hasta C.

LabVIEW fue una mejora importante debido a sus extensas bibliotecas para la adquisición y análisis de datos.Sin embargo, hay que aprender un paradigma diferente.Y definitivamente necesitas un trackball ;-))

No sé nada sobre LabView (ni mucho sobre C/C++), pero...

¿Crees que los lenguajes gráficos como LabVEIW son el futuro de la programación?

No...

¿Es más fácil aprender un lenguaje gráfico que un lenguaje textual?Creo que deberían ser igualmente difíciles de aprender.

¿Más fácil de aprender?No, pero ellos son más fácil de explicar y comprender.

Para explicar un lenguaje de programación hay que explicar qué es una variable (lo cual es sorprendentemente difícil).Esto no es un problema con las herramientas de codificación de diagramas de flujo/nodos, como la interfaz de programación LEGO Mindstroms o Quartz Composer.

Por ejemplo, Este es un programa LEGO Mindstroms bastante complicado. - es muy fácil entender lo que está pasando...pero ¿qué pasa si quieres que el robot ejecute el INCREASEJITTER bloquear 5 veces, luego avanzar durante 10 segundos y luego intentar el bucle INCREASEJITTER nuevamente.Las cosas empiezan a complicarse muy rápidamente.

Quartz Composer es un gran ejemplo de esto y de por qué no creo que los lenguajes gráficos lleguen a ser "el futuro".

Hace que sea muy fácil crear cosas realmente geniales (efectos de partículas 3D, con una cámara controlada por el brillo promedio de los píxeles de una cámara web).pero es increíblemente difícil hacer cosas sencillas, como iterar sobre los elementos de un archivo XML o almacenar ese valor promedio de píxeles en un archivo.

Dado que estamos parcialmente arraigados en ayudar a las personas a aprender, ¿cuánto deberíamos confiar en los módulos preescritos y cuánto deberíamos intentar escribir por nuestra cuenta?("Los buenos programadores escriben buen código, los grandes programadores copian código excelente". ¿Pero no vale la pena ser un buen programador primero?)

Para aprender, es mucho más fácil explicar y comprender un lenguaje gráfico.

Dicho esto, recomendaría un lenguaje especializado basado en texto como progresión.Por ejemplo, para gráficos algo como Procesando o Caja de nodos.Son lenguajes "normales" (Processing es Java, NodeBox es Python) con marcos muy especializados y fáciles de usar (pero absurdamente poderosos) integrados en ellos.

Es importante destacar que son lenguajes muy interactivos, no es necesario escribir cientos de líneas solo para que aparezca un círculo en la pantalla.solo escribe oval(100, 200, 10, 10) y presiona el botón ejecutar, ¡y aparece!Esto también los hace muy fáciles de demostrar y explicar.

Más relacionado con la robótica, incluso algo como LOGO sería una buena introducción: escribes "ADELANTE 1" y la tortuga avanza una casilla.Escriba "LEFT 90" y girará 90 grados.Esto se relaciona con la realidad de manera muy simple.Puede visualizar lo que hará cada instrucción, luego probarla y confirmar que realmente funciona de esa manera.

Muéstreles cosas de aspecto brillante, ellos aprenderán las cosas útiles que aprenderán de C a lo largo del camino, si están interesados ​​o progresan hasta el punto en que necesitan un lenguaje "real", tendrán todo ese conocimiento, en lugar de encontrarse con el error de sintaxis y compilar la pared de ladrillos.

Parece que si está intentando preparar a nuestro equipo para un futuro en programación, C(++) puede ser la mejor ruta.La promesa de los lenguajes de programación generales que se construyen con bloques de construcción visuales nunca parece materializarse y estoy empezando a preguntarme si alguna vez lo harán.Parece que si bien se puede hacer para dominios de problemas específicos, una vez que intentas resolver muchos problemas generales, un lenguaje de programación basado en texto es difícil de superar.

Hubo un tiempo en que me había convencido de la idea de UML ejecutable, pero parece que una vez que superas las relaciones entre objetos y algunos de los flujos de proceso, UML sería una forma bastante miserable de crear una aplicación.Imagínese intentar conectarlo todo a una GUI.No me importaría que me demuestren que estoy equivocado, pero hasta ahora parece poco probable que programemos apuntando y haciendo clic en el corto plazo.

Comencé con LabVIEW hace aproximadamente 2 años y ahora lo uso todo el tiempo, por lo que puede ser parcial, pero lo encuentro ideal para aplicaciones donde están involucradas la adquisición y el control de datos.

Usamos LabVIEW principalmente para pruebas en las que tomamos medidas continuas y controlamos válvulas de gas y gabinetes ATE.Esto implica entradas y salidas digitales y analógicas con rutinas de análisis de señales y control de procesos, todo ejecutándose desde una GUI.Al dividir cada parte en subVI, podemos reconfigurar las pruebas con solo hacer clic y arrastrar el mouse.

No es exactamente lo mismo que C/C++, pero una implementación similar de medición, control y análisis usando Visual BASIC parece compleja y difícil de mantener en comparación.

Creo que el proceso de programación es más importante que el lenguaje de codificación real y debes seguir las pautas de estilo de un lenguaje de programación gráfico.Los diagramas de bloques de LabVIEW muestran el flujo de datos (Programación de flujo de datos) por lo que debería ser fácil ver las posibles condiciones de carrera, aunque nunca he tenido ningún problema.Si tiene un código base C, compilarlo en una DLL permitirá que LabVIEW lo llame directamente.

Definitivamente ambas opciones tienen ventajas;sin embargo, dado que su dominio es una experiencia educativa, creo que una solución C/C++ beneficiaría más a los estudiantes.La programación gráfica siempre será una opción, pero simplemente no proporciona la funcionalidad de una manera elegante que la haría más eficiente de usar que la programación textual para programación de bajo nivel.Esto no es malo: el objetivo de la abstracción es permitir una nueva comprensión y visión del dominio del problema.La razón por la que creo que muchos pueden estar decepcionados con la programación gráfica es que, para cualquier programa en particular, la ganancia incremental al pasar de la programación en C a la programación gráfica no es ni de lejos la misma que la de pasar de la programación ensambladora a C.

El conocimiento de la programación gráfica seguramente beneficiará a cualquier futuro programador.Probablemente habrá oportunidades en el futuro que solo requieran conocimientos de programación gráfica y tal vez algunos de sus estudiantes podrían beneficiarse de alguna experiencia temprana con ella.Por otro lado, una base sólida en conceptos fundamentales de programación proporcionada por un enfoque textual beneficiará todo de sus estudiantes y seguramente debe ser la mejor respuesta.

El capitán del equipo piensa que Labview es mejor por su facilidad de aprendizaje y enseñanza.¿Es eso cierto?

Dudo que eso sea cierto para cualquier idioma o paradigma.LabView seguramente podría ser más fácil para personas con experiencia en ingeniería electrónica;hacer programas en él es "simplemente" dibujar cables.Por otra parte, es posible que esas personas también estén expuestas a la programación.

Una diferencia esencial, además del gráfico, es que LV es una programación basada en la demanda (flujo).Se parte del resultado y se dice qué se necesita para llegar a él.La programación tradicional tiende a ser imperativa (y al revés).

Algunos idiomas pueden proporcionar ambos.Recientemente creé una biblioteca de subprocesos múltiples para Lua (Lanes) y se puede usar para programación basada en la demanda en un entorno que de otro modo sería imperativo.Sé que hay robots exitosos que se ejecutan principalmente en Lua (Iván el loco en Lua Oh Six).

¿Has echado un vistazo a Microsoft Robotics Studio?http://msdn.microsoft.com/en-us/robotics/default.aspx

Permite programación visual (VPL):http://msdn.microsoft.com/en-us/library/bb483047.aspxasí como lenguajes modernos como C#.Te animo a que al menos eches un vistazo a los tutoriales.

Mi queja contra Labview (y Matlab a este respecto) es que si planeas incrustar el código en cualquier otro que no sea x86 (y Labview tiene herramientas para colocar VI de Labview en ARM), entonces tendrás que dedicar toda la potencia posible al problema. como puedas porque es ineficiente.

Labview es una gran herramienta de creación de prototipos:muchas bibliotecas, bloques fáciles de unir, tal vez un poco difícil de hacer algoritmos avanzados, pero probablemente haya un bloque para lo que quieres hacer.Puede realizar la funcionalidad rápidamente.Pero si crees que puedes tomar ese VI y simplemente ponerlo en un dispositivo, estás equivocado.Por ejemplo, si crea un bloque sumador en Labview, tendrá dos entradas y una salida.¿Cuál es el uso de memoria para eso?¿Tres variables de datos?¿Dos?En C o C++ ya sabes, porque puedes escribir z=x+y o x+=y y sabrá exactamente qué está haciendo su código y cuál es la situación de la memoria.El uso de memoria puede aumentar rápidamente, especialmente porque (como otros han señalado) Labview es altamente paralelo.Así que prepárate para solucionar el problema con más RAM de la que pensabas.Y más potencia de procesamiento.

En resumen, Labview es excelente para la creación rápida de prototipos, pero en otras situaciones se pierde demasiado control.Si está trabajando con grandes cantidades de datos o memoria/potencia de procesamiento limitada, utilice un lenguaje de programación basado en texto para poder controlar lo que sucede.

La gente siempre compara labview con C++ y el día "oh, labview es de alto nivel y tiene muchas funciones integradas. Intente adquirir datos haciendo un dfft y mostrar los datos. Es muy fácil en labview, pruébelo en C++".

Mito 1:Es difícil hacer algo con C++ porque su nivel es muy bajo y Labview ya tiene muchas cosas implementadas.El problema es que si está desarrollando un sistema robótico en C++ DEBE usar bibliotecas como opencv, pcl...etc. y sería aún más inteligente si utilizara un marco de software diseñado para construir sistemas robóticos como ROS (sistema operativo de robot).Por lo tanto, es necesario utilizar un conjunto completo de herramientas.De hecho, hay más herramientas de alto nivel disponibles cuando usa ROS + python/c++ con bibliotecas como opencv y pcl.He usado la robótica de Labview y, francamente, los algoritmos de uso común como ICP no están ahí y no es como si ahora pudieras usar otras bibliotecas fácilmente.

Mito 2:¿Es más fácil entender los lenguajes de programación gráficos?

Depende de la situación.Cuando codifica un algoritmo complicado, los elementos gráficos ocuparán un valioso espacio en la pantalla y será difícil comprender el método.Para comprender el código de Labview, debe leer un área de complejidad O (n ^ 2) en el código que acaba de leer de arriba a abajo.

¿Qué pasa si tienes sistemas paralelos?ROS implementa una arquitectura basada en gráficos basada en mensajes de suscriptores/editores implementados mediante devolución de llamada y es bastante fácil tener múltiples programas ejecutándose y comunicándose.Tener componentes paralelos individuales separados facilita la depuración.Por ejemplo, recorrer el código de Labview en paralelo es una pesadilla porque el flujo de control salta de un lugar a otro.En ROS no dibujas explícitamente tu arquitectura como en labview, sin embargo, aún puedes verla ejecutando el comando ros run rqt_graph (que mostrará todos los nodos conectados)

"El futuro de la programación es gráfico". (¿Eso creo?)

Espero que no, la implementación actual de labview no permite codificar utilizando métodos basados ​​en texto y métodos gráficos.(existe mathscript, sin embargo, esto es increíblemente lento)

Es difícil depurar porque no se puede ocultar el paralelismo fácilmente.

Es difícil leer el código de Labview porque hay que revisar mucha área.

Labview es excelente para datos aq y procesamiento de señales, pero no para robótica experimental, porque faltan la mayoría de los componentes de alto nivel como SLAM (localización y mapeo simultáneos), registro de nubes de puntos, procesamiento de nubes de puntos, etc.Incluso si agregan estos componentes y son fáciles de integrar como en ROS, debido a que labview es propietario y costoso, nunca estarán a la altura de la comunidad de código abierto.

En resumen, si labview es el futuro de la mecatrónica, estoy cambiando mi carrera profesional hacia la banca de inversión...Si no puedo disfrutar de mi trabajo, también puedo ganar algo de dinero y jubilarme anticipadamente...

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top