Linguagens de programação textual versus gráfica

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

Pergunta

Faço parte de uma equipe de robótica do ensino médio e há debates sobre qual linguagem usar para programar nosso robô.Estamos escolhendo entre C (ou talvez C++) e LabVIEW.Existem vantagens para cada idioma.

C(++):

  • Amplamente utilizado
  • Boa preparação para o futuro (a maioria dos cargos de programação exige programadores baseados em texto).
  • Podemos expandir nossa base de código C do ano passado
  • Nos permite entender melhor o que nosso robô está fazendo.

LabVIEW

  • Mais fácil de visualizar o fluxo do programa (blocos e fios, em vez de linhas de código)
  • Mais fácil de ensinar (supostamente...)
  • "O futuro da programação é gráfico." (Pensa assim?)
  • Mais próximo do histórico do Robolab que alguns novos membros podem ter.
  • Não precisa saber intimamente o que está acontecendo.Basta dizer ao módulo para encontrar a bola vermelha, não precisa saber como.

Esta é uma decisão muito difícil para nós e estamos debatendo há algum tempo.Com base nas vantagens de cada idioma e na experiência que você tem, qual você acha que é a melhor opção? Tenha em mente que não estamos necessariamente buscando pura eficiência.Também esperamos preparar nossos programadores para um futuro na programação.

Também:

  • Você acha que linguagens gráficas como o LabVEIW são o futuro da programação?
  • Uma linguagem gráfica é mais fácil de aprender do que uma linguagem textual? Eu acho que eles deveriam ser igualmente desafiadores para aprender.
  • Visto que estamos parcialmente enraizados em ajudar as pessoas a aprender, quanto devemos confiar em módulos pré-escritos e quanto devemos tentar escrever por conta própria? (“Bons programadores escrevem bons códigos, grandes programadores copiam ótimos códigos.” Mas não vale a pena ser um bom programador primeiro?)

Obrigado pelo conselho!

Editar:Gostaria de enfatizar mais esta questão:O capitão da equipe acha que o LabVIEW é melhor pela facilidade de aprendizado e ensino. Isso é verdade? Acho que C poderia ser ensinado com a mesma facilidade, e tarefas de nível iniciante ainda existiriam com C.Eu realmente gostaria de ouvir suas opiniões. Existe alguma razão para que digitar while{} seja mais difícil do que criar uma "caixa while"? Não é tão intuitivo que o programa flua linha por linha, modificado apenas por ifs e loops, quanto é intuitivo que o programa flua através do fio, modificado apenas por ifs e loops!?

Obrigado novamente!

Editar:Acabei de perceber que isso se enquadra no tema do "debate linguístico". Espero que esteja tudo bem, porque é sobre o que é melhor para um ramo específico da programação, com certos objetivos.Se não for...Desculpe...

Foi útil?

Solução

Antes de eu chegar, nosso grupo (cientistas com doutorado, com pouca experiência em programação) vinha tentando implementar uma aplicação LabVIEW intermitentemente há quase um ano.O código estava desarrumado, muito complexo (front e back-end) e, o mais importante, não funcionava.Sou um programador entusiasta, mas nunca usei o LabVIEW.Com uma pequena ajuda de um guru do LabVIEW que poderia ajudar a traduzir os paradigmas de programação textual que eu conhecia em conceitos do LabVIEW, foi possível codificar o aplicativo em uma semana.O ponto aqui é que os conceitos básicos de codificação ainda precisam ser aprendidos, a linguagem, mesmo uma como o LabVIEW, é apenas uma maneira diferente de expressá-los.

O LabVIEW é ótimo para usar naquilo para o qual foi originalmente projetado.ou sejapara pegar dados de cartões DAQ e exibi-los na tela, talvez com algumas pequenas manipulações intermediárias.Porém, a programação algoritmos não é mais fácil e eu até sugeriria que é mais difícil.Por exemplo, na maioria das linguagens procedurais, a ordem de execução é geralmente seguida linha por linha, usando notação pseudo-matemática (ou seja, y = x*x + x + 1) enquanto o LabVIEW implementaria isso usando uma série de VIs que não necessariamente seguem um do outro (ou seja,da esquerda para a direita) na tela.

Além disso, programar como carreira é mais do que conhecer os detalhes técnicos da codificação.Ser capaz de pedir ajuda/buscar respostas de maneira eficaz, escrever código legível e trabalhar com código legado são habilidades essenciais que são inegavelmente mais difíceis em uma linguagem gráfica como o LabVIEW.

Acredito que alguns aspectos da programação gráfica podem se tornar populares - o uso de sub-VIs incorpora perfeitamente o princípio da 'caixa preta' da programação e também é usado em outras abstrações de linguagem, como Tubos do Yahoo e o Apple Automator - e talvez alguma linguagem gráfica futura revolucione a maneira como programamos, mas o LabVIEW em si não é uma grande mudança de paradigma no design de linguagens, ainda temos while, for, if controle de fluxo, conversão de tipos, programação orientada a eventos e até objetos.Se o futuro realmente for escrito em LabVIEW, o programador C++ não terá muitos problemas para fazer a transição.

Como pós-escrito, eu diria que C/C++ é mais adequado para robótica, já que os alunos sem dúvida terão que lidar com sistemas embarcados e FPGAs em algum momento.Conhecimento de programação de baixo nível (bits, registradores etc.) seria inestimável para esse tipo de coisa.

@mendicante Na verdade o LabVIEW é muito utilizado na indústria, principalmente para sistemas de controle.É improvável que a NASA o utilize para sistemas de satélite a bordo, mas o desenvolvimento de software para sistemas espaciais é uma tarefa jogo de bola totalmente diferente...

Outras dicas

Encontrei uma situação semelhante no grupo de pesquisa em que trabalho atualmente.É um grupo de biofísica e estamos usando o LabVIEW em todos os lugares para controlar nossos instrumentos.Isso funciona perfeitamente:é fácil montar uma UI para controlar todos os aspectos dos seus instrumentos, visualizar seu status e salvar seus dados.

E agora tenho que me impedir de escrever um discurso retórico de 5 páginas, porque para mim o LabVIEW tem sido um pesadelo.Deixe-me tentar resumir alguns prós e contras:

Isenção de responsabilidade Não sou um especialista em LabVIEW, posso dizer coisas tendenciosas, desatualizadas ou simplesmente erradas :)

Profissionais do LabVIEW

  • Sim, é fácil de aprender.Muitos PhDs do nosso grupo parecem ter adquirido habilidades suficientes para serem eliminados em poucas semanas, ou até menos.
  • Bibliotecas.Este é um ponto importante.Você teria que investigar isso cuidadosamente para sua própria situação (não sei do que você precisa, se existem boas bibliotecas do LabVIEW para isso ou se existem alternativas em outras linguagens).No meu caso, encontrar, por exemplo, uma biblioteca de gráficos boa e rápida em Python tem sido um grande problema, o que me impediu de reescrever alguns de nossos programas em Python.
  • Sua escola pode já tê-lo instalado e funcionando.

Contras do LabVIEW

  • É talvez também fácil de aprender.De qualquer forma, parece que ninguém realmente se preocupa em aprender as melhores práticas, então os programas rapidamente se tornam uma bagunça completa e irreparável.Claro, isso também acontecerá com linguagens baseadas em texto se você não tomar cuidado, mas na IMO é muito mais difícil fazer as coisas corretamente no LabVIEW.
  • Tende a haver principais problemas no LabVIEW para encontrar sub-VIs (até a versão 8.2, eu acho).O LabVIEW possui sua própria maneira de saber onde encontrar bibliotecas e sub-VIs, o que torna muito fácil quebrar completamente o seu software.Isso torna os projetos grandes um incômodo se você não tiver alguém por perto que saiba como lidar com isso.
  • Fazer o LabVIEW funcionar com controle de versão é uma dor.Claro, isso pode ser feito, mas de qualquer forma eu evitaria usar o VC integrado.Confira LVDiff para uma ferramenta de comparação do LabVIEW, mas nem pense em mesclar.

(Os dois últimos pontos dificultam o trabalho em equipe em um projeto.Isso provavelmente é importante no seu caso)

  • Isto é pessoal, mas acho que muitos algoritmos simplesmente não funcionam quando programados visualmente. É uma bagunça.
    • Um exemplo são coisas estritamente sequenciais;isso fica complicado muito rapidamente.
    • É difícil ter uma visão geral do código.
    • Se você usar sub-VIs para tarefas pequenas (assim como é uma boa prática criar funções que executem uma tarefa pequena e que caibam em uma tela), você não pode apenas dar nomes a eles, mas também desenhar ícones para cada um. deles.Isso fica muito chato e complicado em apenas alguns minutos, então você fica muito tentado não para colocar coisas em um sub-VI.É muito incômodo.Por falar nisso:fazer um ícone realmente bom pode levar horas profissionais.Tente criar um ícone único, imediatamente compreensível e reconhecível para cada sub-VI que você escrever :)
  • Você terá túnel do carpo dentro de uma semana.Garantido.
  • @Brendan:Ouça ouça!

Observações finais

Quanto à sua pergunta "devo escrever meus próprios módulos":Eu não tenho certeza.Depende de suas restrições de tempo.Não perca tempo reinventando a roda se não for necessário.É muito fácil passar dias escrevendo código de baixo nível e então perceber que seu tempo acabou.Se isso significa que você escolheu o LabVIEW, vá em frente.

Se houvesse maneiras fáceis de combinar LabVIEW e, por exemplo, C++, eu adoraria ouvir sobre isso:isso pode lhe dar o melhor dos dois mundos, mas duvido que existam.

Mas certifique-se de que você e sua equipe dediquem tempo aprendendo as melhores práticas.Olhando para o código um do outro.Aprendendo uns com os outros.Escrever código utilizável e compreensível.E se divertindo!

E, por favor, perdoe-me por parecer nervoso e talvez um tanto pedante.Acontece que o LabVIEW tem sido um real pesadelo para mim :)

Acho que a escolha do LabVIEW ou não depende de você querer aprender a programar em uma linguagem comumente usada como uma habilidade comercializável ou apenas querer fazer as coisas.O LabVIEW permite que você realize tarefas de forma muito rápida e produtiva.Como outros observaram, isso não o liberta magicamente de ter que entender o que está fazendo, e é bem possível criar uma bagunça profana se você não o fizer - embora, de forma anedótica, os piores exemplos de estilo de codificação ruim no LabVIEW sejam geralmente perpetrado por pessoas que têm experiência em linguagem de texto e se recusam a se adaptar ao funcionamento do LabVIEW porque 'já sabem programar, caramba!'

Isso não quer dizer que a programação em LabVIEW não seja uma habilidade comercializável, é claro;só que não é tão popular quanto o C++.

O LabVIEW torna extremamente fácil gerenciar diferentes coisas acontecendo em paralelo, o que você pode muito bem ter em uma situação de controle de robô.As condições de corrida no código que deveriam ser sequenciais também não deveriam ser um problema (ou seja,se estiverem, você está fazendo errado):existem técnicas simples para garantir que as coisas aconteçam na ordem correta quando necessário - encadeamento de subVIs usando o fio de erro ou outros dados, usando notificadores ou filas, construindo uma estrutura de máquina de estado, até mesmo usando a estrutura de sequência do LabVIEW, se necessário.Novamente, isso é simplesmente uma questão de dedicar algum tempo para entender as ferramentas disponíveis no LabVIEW e como elas funcionam.Não acho que a reclamação de ter que criar ícones subVI seja muito bem direcionada;você pode criar rapidamente um contendo algumas palavras de texto, talvez com uma cor de fundo, e isso servirá para a maioria dos propósitos.

'Serão as linguagens gráficas o caminho do futuro' é uma pista falsa baseada numa falsa dicotomia.Algumas coisas são adequadas para linguagens gráficas (código paralelo, por exemplo);outras coisas se adequam muito melhor aos idiomas de texto.Não espero que o LabVIEW e a programação gráfica desapareçam ou dominem o mundo.

Aliás, eu ficaria muito surpreso se a NASA não use LabVIEW no programa espacial.Alguém descreveu recentemente na lista de discussão do Info-LabVIEW como eles usaram o LabVIEW para desenvolver e testar o controle de circuito fechado de superfícies de vôo acionadas por motores elétricos no Boeing 787, e deu a impressão de que o LabVIEW foi usado extensivamente no desenvolvimento do avião.Também é usado para controle em tempo real no Grande Colisor de Hádrons!

O local mais ativo atualmente para obter mais informações e ajuda com o LabVIEW, além do próprio site e fóruns da National Instruments, parece ser LAVA.

Isso não responde diretamente à sua pergunta, mas você pode considerar uma terceira opção de mixagem em uma linguagem interpretada. Lua, por exemplo, é já usado no campo da robótica.É rápido, leve e pode ser configurado para funcionar com números de ponto fixo em vez de ponto flutuante, já que a maioria dos microcontroladores não possui FPU. Adiante é outra alternativa com uso semelhante.

Deve ser muito fácil escrever uma fina camada de interface em C e depois deixar os alunos à vontade com scripts interpretados.Você pode até configurá-lo para permitir que o código seja carregado dinamicamente sem recompilar e atualizar um chip.Isto deve reduzir o ciclo de iteração e permitir que os alunos aprendam melhor, vendo os resultados mais rapidamente.

Eu sou tendencioso contra usando ferramentas visuais como LabVIEW.Sempre pareço acertar algo que não funciona ou não funciona exatamente como eu gostaria.Então, prefiro o controle absoluto que você obtém com o código textual.

O outro ponto forte do LabVIEW (além das bibliotecas) é simultaneidade.É um linguagem de fluxo de dados, o que significa que o tempo de execução pode lidar com a simultaneidade para você.Portanto, se você estiver fazendo algo altamente simultâneo e não quiser fazer a sincronização tradicional, o LabVIEW pode ajudá-lo.

O futuro não pertence às linguagens gráficas como elas são hoje.Pertence a quem consegue criar uma representação do fluxo de dados (ou outro tipo de programação amigável à simultaneidade) que seja tão simples quanto a abordagem gráfica, mas que também possa ser analisada pelas próprias ferramentas do programador.

Há um estudo publicado sobre o tema hospedado pela National Instruments:

Um estudo de gráficos vs.Programação Textual para Ensino de DSP

Ele analisa especificamente o LabVIEW versus MATLAB (em oposição ao C).

Acho que as linguagens gráficas sempre serão limitadas em expressividade em comparação às textuais.Compare a tentativa de comunicação por meio de símbolos visuais (por exemplo, REBUS ou linguagem de sinais) com a comunicação por meio de palavras.

Para tarefas simples, usar uma linguagem gráfica geralmente é mais fácil, mas para lógicas mais complexas, acho que as linguagens gráficas atrapalham.

Outro debate implícito neste argumento, porém, é a programação declarativa vs.imperativo.Declarativo geralmente é melhor para qualquer coisa em que você realmente não precise de um controle refinado sobre como algo é feito.Você pode use C++ de forma declarativa, mas você precisaria de mais trabalho inicial para fazê-lo, enquanto LABView foi projetado como uma linguagem declarativa.

Uma imagem vale mais que mil palavras, mas se uma imagem representa mil palavras que você não precisa e não pode mudar isso, então, nesse caso, uma imagem não vale nada.Já você pode criar milhares de imagens usando palavras, especificando cada detalhe e até mesmo direcionando explicitamente o foco do espectador.

O LabVIEW permite que você comece rapidamente e (como outros já disseram) possui uma enorme biblioteca de código para fazer vários testes, medições e coisas relacionadas ao controle.

A maior desvantagem do LabVIEW, porém, é que você perde todas as ferramentas que os programadores escrevem para si mesmos.

Seu código é armazenado como VIs.Estes são arquivos binários opacos.Isso significa que seu código realmente não é seu, é do LabVIEW.Você não pode escrever seu próprio analisador, não pode escrever um gerador de código, não pode fazer alterações automatizadas por meio de macros ou scripts.

Esse é uma merda quando você tem um aplicativo 5000 VI que precisa de alguns pequenos ajustes aplicados universalmente.Seu apenas A opção é passar por cada VI manualmente, e Deus o ajude se você perder uma alteração em um VI em algum canto em algum lugar.

E sim, como é binário, você não pode fazer diff/merge/patch como faz com linguagens textuais.Na verdade, isso torna o trabalho com mais de uma versão do código um terrível pesadelo de manutenção.

Certamente, use o LabVIEW se você estiver fazendo algo simples, ou precisar prototipar, ou não planejar manter seu código.

Se você quiser fazer uma programação real e sustentável, use uma linguagem textual.Você pode ser mais lento no início, mas será mais rápido no longo prazo.

(Ah, e se você precisar de bibliotecas DAQ, a NI também possui versões C++ e .Net delas.)

Meu primeiro post aqui :) seja gentil...

Venho de uma experiência consolidada na indústria automotiva e agora estou na indústria de defesa.Posso dizer por experiência própria que C/C++ e LabVIEW são feras realmente diferentes com propósitos diferentes em mente.C/C++ sempre foi usado para o trabalho embarcado em microcontroladores porque era compacto e compiladores/ferramentas eram fáceis de encontrar.O LabVIEW, por outro lado, foi usado para controlar o sistema de teste (juntamente com a bancada de teste como sequenciador).A maioria dos equipamentos de teste que usamos eram da NI, então o LabVIEW forneceu um ambiente onde tínhamos as ferramentas e os drivers necessários para o trabalho, junto com o suporte que desejávamos.

Em termos de facilidade de aprendizado, existem muitos recursos disponíveis para C/C++ e muitos sites que apresentam considerações de design e exemplos de algoritmos em praticamente qualquer coisa que você procura, disponível gratuitamente.Para o LabVIEW, a comunidade de usuários provavelmente não é tão diversa quanto C/C++, e é preciso um pouco mais de esforço para inspecionar e comparar o código de exemplo (é necessário ter a versão correta do LabVIEW, etc.) ...Achei o LabVIEW muito fácil de aprender e aprender, mas há alguns incômodos, como alguns mencionaram aqui, relacionados ao paralelismo e várias outras coisas que exigem um pouco de experiência antes de você se tornar consciente delas.

Então a conclusão depois de tudo isso?Eu diria que vale a pena aprender AMBAS as linguagens porque elas realmente representam dois estilos diferentes de programação e certamente vale a pena estar atento e proficiente em ambos.

Oh meu Deus, a resposta é tão simples.Usar LabView.

Eu programo sistemas embarcados há 10 anos e posso dizer que sem pelo menos alguns meses de infraestrutura (infraestrutura muito cuidadosa!), você não será tão produtivo quanto no primeiro dia com LabView.

Se você está projetando um robô para ser vendido e usado pelas forças armadas, vá em frente e comece com C – é uma boa decisão.

Caso contrário, utilize o sistema que lhe permite experimentar a maior variedade no menor tempo possível.Isso é LabView.

Eu acho que as linguagens gráficas podem ser a linguagem do futuro.....para todos os desenvolvedores ad hoc do MS Access por aí.Sempre haverá um lugar para os codificadores puramente textuais.

Pessoalmente, tenho que perguntar qual é a verdadeira diversão em construir um robô se tudo for feito para você?Se você simplesmente colocar um módulo 'encontre a bola vermelha' lá e vê-lo passar?Que sentimento de orgulho você terá por sua realização?Pessoalmente, eu não teria muito.Além disso, o que isso vai te ensinar sobre codificação ou sobre o aspecto (muito importante) da interface de software/hardware que é crítico na robótica?

Não tenho a pretensão de ser um especialista na área, mas pergunte-se uma coisa:Você acha que a NASA usou o LabVIEW para codificar os Mars Rovers?Você acha que alguém realmente proeminente na robótica está usando o LabView?

Realmente, se você me perguntar, a única coisa para a qual usar coisas pré-fabricadas como o LabVIEW para construir isso vai prepará-lo é para ser um construtor de robôs de quintal e nada mais.Se você deseja algo que lhe proporcione algo mais parecido com experiência no setor, construa seu próprio sistema do tipo 'LabVIEW'.Crie seu próprio módulo de encontrar a bola ou seu próprio módulo de 'siga a linha'.Será muito mais difícil, mas também será muito mais legal.:D

Eu adoro o LabVIEW.Eu recomendo fortemente, especialmente se os outros lembrares usaram algo semelhante.Demora um pouco para os programadores normais se acostumarem, mas os resultados são muito melhores se você já sabe programar.

C/C++ é igual a gerenciar sua própria memória.Você estará nadando em links de memória e se preocupando com eles.Vá com o LabVIEW e certifique-se de ler a documentação que vem com o LabVIEW e esteja atento às condições de corrida.

Aprender um idioma é fácil.Aprender a programar não é.Isso não muda, mesmo que seja uma linguagem gráfica.A vantagem das linguagens gráficas é que é mais fácil visualizar o que o código fará, em vez de ficar parado e decifrar um monte de texto.

O importante não é a linguagem, mas os conceitos de programação.Não importa em que linguagem você aprenda a programar, porque com um pouco de esforço você será capaz de programar bem em qualquer linguagem.As línguas vêm e vão.

Isenção de responsabilidade:Não testemunhei o LabVIEW, mas usei algumas outras linguagens gráficas, incluindo WebMethods Flow e Modeller, linguagens de simulação dinâmica na universidade e, er, Scratch do MIT :).

Minha experiência é que as linguagens gráficas podem fazer um bom trabalho na parte de 'encanamento' da programação, mas as que usei ativamente atrapalham a algorítmica.Se seus algoritmos forem muito simples, tudo bem.

Por outro lado, também não acho que C++ seja ótimo para sua situação.Você gastará mais tempo rastreando problemas de gerenciamento de ponteiro e memória do que em trabalhos úteis.

Se o seu robô puder ser controlado usando uma linguagem de script (Python, Ruby, Perl, qualquer que seja), então acho que seria uma escolha muito melhor.

Depois, há opções híbridas:

Se não houver opção de script para o seu robô e você tiver um geek de C++ em sua equipe, considere fazer com que esse geek escreva ligações para mapear sua biblioteca C++ para uma linguagem de script.Isso permitiria que pessoas com outras especialidades programassem o robô com mais facilidade.As encadernações seriam um bom presente para a comunidade.

Se o LabVIEW permitir, use sua linguagem gráfica para reunir módulos escritos em linguagem textual.

Você está no ensino médio.Quanto tempo você tem para trabalhar neste programa?Quantas pessoas estão no seu grupo?Eles já conhecem C++ ou LabView?

Pela sua pergunta, vejo que você conhece C++ e a maior parte do grupo não.Suspeito também que o líder do grupo seja perspicaz o suficiente para perceber que alguns membros da equipe podem se sentir intimidados por uma linguagem de programação baseada em texto.Isso é aceitável, você está no ensino médio e essas pessoas estão normies.Sinto que alunos normais do ensino médio serão capazes de entender o LabView de forma mais intuitiva do que o C++.Suponho que a maioria dos estudantes do ensino médio, assim como a população em geral, tem medo de linha de comando.Para você a diferença é muito menor, mas para eles é noite e dia.

Você está certo de que os mesmos conceitos podem ser aplicados ao LabView e ao C++.Cada um tem seus pontos fortes e fracos.A chave é selecionar a ferramenta certa para o trabalho.LabView foi projetado para este tipo de aplicação.C++ é muito mais genérico e pode ser aplicado a muitos outros tipos de problemas.

Vou recomendar o LabView.Com o hardware certo, você pode começar a trabalhar quase imediatamente.Sua equipe pode passar mais tempo fazendo com que o robô faça o que você quiser, que é o foco desta atividade.

As linguagens gráficas não são o futuro da programação;há muitos anos que são uma das opções disponíveis, criadas para resolver determinados tipos de problemas.O futuro da programação é camada após camada de abstração do código de máquina.No futuro, estaremos nos perguntando por que perdemos todo esse tempo programando “semântica” repetidamente.

quanto devemos confiar em módulos pré-escritos e quanto devemos tentar escrever por conta própria?Você não deve perder tempo reinventando a roda.Se houver drivers de dispositivos disponíveis no Labview, use-os.Você pode aprender muito copiando código com função semelhante e adaptando-o às suas necessidades - você verá como outras pessoas resolveram problemas semelhantes e terá que interpretar a solução deles antes de poder aplicá-la adequadamente ao seu problema.Se você copiar o código cegamente, as chances de fazê-lo funcionar são mínimas.Você tem que ser bom, mesmo copiando código.

Boa sorte!

Eu sugiro que você use o LabVIEW, pois você pode fazer do robô o que deseja de maneira mais rápida e fácil.O LabVIEW foi projetado pensando nisso.É claro que C(++) são ótimas linguagens, mas o LabVIEW faz o que deve fazer melhor do que qualquer outra coisa.As pessoas podem escrever softwares realmente bons no LabVIEW, pois ele fornece amplo escopo e suporte para isso.

Há uma coisa enorme que achei negativa no uso do LabVIEW para minhas aplicações:Organize a complexidade do design.Como físico, considero o Labview ótimo para prototipagem, controle de instrumentos e análise matemática.Não existe nenhuma linguagem em que você obtenha resultados melhores e mais rápidos do que no LabVIEW.Eu uso o LabView desde 1997.Desde 2005 mudei completamente para o framework .NET, por ser mais fácil de projetar e manter.

No LabVIEW uma estrutura simples 'if' deve ser desenhada e ocupa muito espaço no seu design gráfico.Acabei de descobrir que muitas de nossas aplicações comerciais eram difíceis de manter.Quanto mais complexo o aplicativo se tornava, mais difícil era a leitura.

Agora uso idiomas de texto e sou muito melhor na manutenção de tudo.Se você comparasse C++ com LabVIEW eu usaria LabVIEW, mas comparado com C# ele não vence

Como sempre, depende.

Eu uso o LabVIEW há cerca de 20 anos e fiz vários tipos de trabalhos, desde DAQ simples até visualizações muito complexas, desde controles de dispositivos até sequenciadores de teste.Se não fosse bom o suficiente, eu com certeza teria trocado.Dito isso, comecei a codificar Fortran com cartões perfurados e usei muitas linguagens de programação em 'máquinas' de 8 bits, começando pelas baseadas em Z80.As linguagens variavam de Assembler a BASIC, de Turbo-Pascal a C.

O LabVIEW foi uma grande melhoria devido às suas extensas bibliotecas para aquisição e análise de dados.É preciso, no entanto, aprender um paradigma diferente.E você definitivamente precisa de um trackball ;-))

Não sei nada sobre LabView (ou muito sobre C/C++), mas ..

Você acha que linguagens gráficas como o LabVEIW são o futuro da programação?

Não...

Uma linguagem gráfica é mais fácil de aprender do que uma linguagem textual?Eu acho que eles deveriam ser igualmente desafiadores para aprender.

Mais fácil de aprender?Não, mas eles são mais fácil de explicar e entender.

Para explicar uma linguagem de programação você precisa explicar o que é uma variável (o que é surpreendentemente difícil).Isso não é um problema com ferramentas de codificação nodal/fluxograma, como a interface de programação LEGO Mindstroms ou Quartz Composer.

Por exemplo, neste é um programa LEGO Mindstroms bastante complicado - é muito fácil entender o que está acontecendo...mas e se você quiser que o robô execute o INCREASEJITTER bloquear 5 vezes, depois avançar por 10 segundos e tentar o loop INCREASEJITTER novamente?As coisas começam a ficar complicadas muito rapidamente.

O Quartz Composer é um ótimo exemplo disso, e por que não acho que as linguagens gráficas jamais "serão o futuro"

Torna muito fácil fazer coisas realmente legais (efeitos de partículas 3D, com uma câmera controlada pelo brilho médio dos pixels de uma webcam).mas é incrivelmente difícil fazer coisas fáceis, como iterar os elementos de um arquivo XML ou armazenar o valor médio de pixel em um arquivo.

Visto que estamos parcialmente enraizados em ajudar as pessoas a aprender, até que ponto devemos confiar em módulos pré-escritos e até que ponto devemos tentar escrever por conta própria?(“Bons programadores escrevem bons códigos, grandes programadores copiam ótimos códigos.” Mas não vale a pena ser um bom programador primeiro?)

Para aprender, é muito mais fácil explicar e compreender uma linguagem gráfica.

Dito isto, eu recomendaria uma linguagem especializada baseada em texto como uma progressão.Por exemplo, para gráficos algo como Em processamento ou NodeBox.São linguagens "normais" (Processing é Java, NodeBox é Python) com estruturas muito especializadas e fáceis de usar (mas absurdamente poderosas) arraigadas nelas.

É importante ressaltar que são linguagens muito interativas, você não precisa escrever centenas de linhas apenas para fazer um círculo na tela.Você acabou de digitar oval(100, 200, 10, 10) e pressione o botão executar, e ele aparece!Isso também os torna muito fáceis de demonstrar e explicar.

Mais relacionado à robótica, até mesmo algo como LOGO seria uma boa introdução - você digita "FORWARD 1" e a tartaruga avança uma caixa.Digite "LEFT 90" e ele gira 90 graus.Isto se relaciona com a realidade de forma muito simples.Você pode visualizar o que cada instrução fará, depois experimentá-la e confirmar se realmente funciona dessa maneira.

Mostre-lhes coisas de aparência brilhante, eles aprenderão as coisas úteis que aprenderam com C ao longo do caminho, se estiverem interessados ​​ou progredirem até o ponto em que precisam de uma linguagem "real", eles terão todo esse conhecimento, em vez de encontre o erro de sintaxe e compile a parede de tijolos.

Parece que se você está tentando preparar nossa equipe para um futuro na programação, C(++) pode ser o melhor caminho.A promessa de linguagens de programação gerais construídas com blocos de construção visuais nunca pareceu se materializar e estou começando a me perguntar se algum dia isso acontecerá.Parece que, embora isso possa ser feito para domínios de problemas específicos, uma vez que você tenta resolver muitos problemas gerais, é difícil vencer uma linguagem de programação baseada em texto.

Certa vez, eu meio que acreditei na ideia da UML executável, mas parece que, depois de superar os relacionamentos de objetos e alguns dos fluxos de processo, a UML seria uma maneira bastante miserável de construir um aplicativo.Imagine tentar conectar tudo a uma GUI.Eu não me importaria de ser provado que estou errado, mas até agora parece improvável que iremos programar apontar e clicar em breve.

Comecei com o LabVIEW há cerca de 2 anos e agora o uso o tempo todo, então posso ser tendencioso, mas acho que é ideal para aplicações onde aquisição e controle de dados estão envolvidos.

Usamos o LabVIEW principalmente para testes onde fazemos medições contínuas e controlamos válvulas de gás e gabinetes ATE.Isso envolve entradas e saídas digitais e analógicas com rotinas de análise de sinal e controle de processo, tudo executado a partir de uma GUI.Ao dividir cada parte em subVIs, podemos reconfigurar os testes clicando e arrastando o mouse.

Não é exatamente o mesmo que C/C++, mas uma implementação semelhante de medição, controle e análise usando Visual BASIC parece complexa e difícil de manter por comparação.

Acho que o processo de programação é mais importante do que a linguagem de codificação em si e você deve seguir as diretrizes de estilo para uma linguagem de programação gráfica.Os diagramas de blocos do LabVIEW mostram o fluxo de dados (Programação de fluxo de dados), então deve ser fácil ver as possíveis condições de corrida, embora eu nunca tenha tido problemas.Se você tiver uma base de código C, construí-la em uma dll permitirá que o LabVIEW a chame diretamente.

Definitivamente, há méritos em ambas as escolhas;no entanto, como seu domínio é uma experiência educacional, acho que uma solução C/C++ beneficiaria mais os alunos.A programação gráfica sempre será uma opção, mas simplesmente não fornece a funcionalidade de uma maneira elegante que tornaria seu uso mais eficiente do que a programação textual para programação de baixo nível.Isso não é uma coisa ruim - o objetivo da abstração é permitir uma nova compreensão e visão do domínio do problema.A razão pela qual acredito que muitos possam ficar desapontados com a programação gráfica é que, para qualquer programa específico, o ganho incremental ao passar da programação em C para a gráfica não é nem de longe o mesmo que passar da montagem para C.

O conhecimento de programação gráfica beneficiaria qualquer futuro programador, com certeza.Provavelmente haverá oportunidades no futuro que exigirão apenas conhecimento de programação gráfica e talvez alguns de seus alunos possam se beneficiar de alguma experiência inicial com ela.Por outro lado, uma base sólida em conceitos fundamentais de programação proporcionada por uma abordagem textual beneficiará todos de seus alunos e certamente deve ser a melhor resposta.

O capitão da equipe acha que o LabVIEW é melhor por sua facilidade de aprendizado e ensino.Isso é verdade?

Duvido que isso seja verdade para qualquer linguagem ou paradigma.O LabView certamente poderia ser mais fácil para pessoas com formação em engenharia eletrônica;fazer programas nele é "simplesmente" desenhar fios.Então, novamente, essas pessoas também podem já estar expostas à programação.

Uma diferença essencial - além do gráfico - é que o LV é uma programação baseada na demanda (fluxo).Você começa a partir do resultado e diz o que é necessário para chegar até ele.A programação tradicional tende a ser imperativa (ao contrário).

Alguns idiomas podem fornecer ambos.Criei recentemente uma biblioteca multithreading para Lua (Lanes) e ela pode ser usada para programação baseada em demanda em um ambiente imperativo.Eu sei que existem robôs de sucesso executados principalmente em Lua por aí (Ivan louco em Lua Oh Seis).

Você já deu uma olhada no Microsoft Robotics Studio?http://msdn.microsoft.com/en-us/robotics/default.aspx

Permite programação visual (VPL):http://msdn.microsoft.com/en-us/library/bb483047.aspxbem como linguagens modernas como C#.Eu encorajo você a pelo menos dar uma olhada nos tutoriais.

Minha reclamação contra o Labview (e o Matlab a esse respeito) é que se você planeja incorporar o código em algo diferente de x86 (e o Labview tem ferramentas para colocar VIs do Labview em ARMs), então você terá que usar o máximo de potência no problema possível porque é ineficiente.

Labview é uma ótima ferramenta de prototipagem:muitas bibliotecas, blocos fáceis de encadear, talvez um pouco difíceis de fazer algoritmos avançados, mas provavelmente há um bloco para o que você deseja fazer.Você pode concluir a funcionalidade rapidamente.Mas se você acha que pode pegar esse VI e colocá-lo em um dispositivo, você está errado.Por exemplo, se você fizer um bloco somador no Labview você terá duas entradas e uma saída.Qual é o uso de memória para isso?Três variáveis ​​que valem dados?Dois?Em C ou C++ você sabe, porque você pode escrever z=x+y ou x+=y e você sabe exatamente o que seu código está fazendo e qual é a situação da memória.O uso da memória pode aumentar rapidamente, especialmente porque (como outros apontaram) o Labview é altamente paralelo.Portanto, esteja preparado para lançar mais RAM do que você pensava no problema.E mais poder de processamento.

Resumindo, o Labview é ótimo para prototipagem rápida, mas você perde muito controle em outras situações.Se você estiver trabalhando com grandes quantidades de dados ou capacidade limitada de memória/processamento, use uma linguagem de programação baseada em texto para poder controlar o que acontece.

As pessoas sempre comparam o labview com C++ e dia "ah, o labview é de alto nível e tem muitas funcionalidades integradas, tente adquirir dados fazendo um dfft e exibindo os dados, é tão fácil no labview, experimente em C++".

Mito 1:É difícil fazer qualquer coisa com C++ porque seu nível é muito baixo e o labview já tem muitas coisas implementadas.O problema é que se você estiver desenvolvendo um sistema robótico em C++ você DEVE usar bibliotecas como opencv , pcl ..ect e você seria ainda mais inteligente se usasse uma estrutura de software projetada para construir sistemas robóticos como ROS (sistema operacional de robô).Portanto, você precisa usar um conjunto completo de ferramentas.Na verdade, existem mais ferramentas de alto nível disponíveis quando você usa ROS + python/c++ com bibliotecas como opencv e pcl.Eu usei robótica labview e, francamente, algoritmos comumente usados ​​como ICP não existem e não é como se você pudesse usar outras bibliotecas facilmente agora.

Mito2:É mais fácil entender linguagens de programação gráfica

Depende da situação.Quando você está codificando um algoritmo complicado, os elementos gráficos ocuparão um espaço valioso na tela e será difícil entender o método.Para entender o código do labview, você precisa ler uma área com complexidade O (n ^ 2) no código que acabou de ler de cima para baixo.

E se você tiver sistemas paralelos.O ROS implementa uma arquitetura baseada em gráficos baseada em mensagens de assinantes/editores implementadas usando retorno de chamada e é muito fácil ter vários programas em execução e se comunicando.Ter componentes paralelos individuais separados facilita a depuração.Por exemplo, percorrer o código labview paralelo é um pesadelo porque o fluxo de controle salta de um lugar para outro.No ROS você não desenha explicitamente sua arquitetura como no labview, no entanto, você ainda pode vê-la executando o comando ros run rqt_graph (que mostrará todos os nós conectados)

"O futuro da programação é gráfico." (Pensa assim?)

Espero que não, a implementação atual do labview não permite a codificação usando métodos baseados em texto e métodos gráficos.(existe mathscript, porém isso é incrivelmente lento)

É difícil depurar porque você não consegue esconder o paralelismo facilmente.

É difícil ler o código do labview porque você precisa examinar muita área.

Labview é ótimo para processamento de dados e sinal, mas não para robótica experimental, porque a maioria dos componentes de alto nível como SLAM (localização e mapeamento simultâneos), registro de nuvem de pontos, processamento de nuvem de pontos, etc., estão faltando.Mesmo que adicionem esses componentes e sejam fáceis de integrar como no ROS, porque o labview é proprietário e caro, eles nunca acompanharão a comunidade de código aberto.

Em resumo, se o labview é o futuro da mecatrônica, estou mudando minha carreira para banco de investimento...Se não consigo aproveitar meu trabalho, posso muito bem ganhar algum dinheiro e me aposentar mais cedo...

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top