Текстовые и графические языки программирования

Я являюсь частью команды роботов средней школы, и есть некоторые споры о том, какой язык использовать для программирования нашего робота. Мы выбираем между C (или, возможно, C ++) и LabVIEW. Есть плюсы для каждого языка.

C (++):

  • Широко используемый
  • Хорошая подготовка к будущему (большинство позиций программирования требуют текстовых программистов.)
  • Мы можем расширить нашу кодовую базу C с прошлого года
  • Позволяет нам лучше понять, что делает наш робот.

LabVIEW

  • Проще визуализировать ход программы (блоки и провода, а не строки кода)
  • Проще учить (предположительно ...)
  • «Будущее программирования графическое». (Думаю да?)
  • Ближе к истории Robolab, что некоторые новые участники могут иметь.
  • Не нужно глубоко знать, что происходит. Просто скажите модулю найти красный шар, не нужно знать, как.

Это очень сложное решение для нас, и мы уже давно обсуждаем это. Исходя из этих плюсов для каждого языка и полученного опыта, как вы думаете , какой вариант лучше? Имейте в виду, что мы не обязательно идем к чистой эффективности. Мы также надеемся подготовить наших программистов к будущему программированию.

Также:

  • Считаете ли вы, что графические языки, такие как LabVEIW, - это будущее программирования?
  • Легче ли изучать графический язык, чем текстовый? Я думаю, что они должны быть примерно одинаково сложными для изучения.
  • Видя, что мы неравнодушны к тому, чтобы помогать людям учиться, насколько мы должны полагаться на заранее написанные модули и сколько мы должны пытаться писать самостоятельно? («Хорошие программисты пишут хороший код, хорошие программисты копируют отличный код. Но разве не стоит быть хорошим программистом, во-первых?)

Спасибо за совет!


Изменить: я хотел бы подчеркнуть этот вопрос больше: капитан команды считает, что LabVIEW лучше для его простоты обучения и преподавания. Это правда? Я думаю, что C можно научить так же легко, и задачи начального уровня все еще будут рядом с C. Мне бы очень хотелось услышать ваше мнение. Есть ли какая-то причина, по которой набирать while {} должно быть сложнее, чем создавать поле while? Разве не настолько интуитивно понятно, что программа перемещается построчно, изменяясь только с помощью ifs и циклов, так как интуитивно понятно, что программа движется через провод, изменяемый только с помощью ifs и циклов !?

Еще раз спасибо!


Редактировать: я только что понял, что это подпадает под тему "языковые дебаты". Я надеюсь, что все в порядке, потому что речь идет о том, что лучше для конкретной отрасли программирования с определенными целями. Если нет ... прости ...

17.08.2008 15:39:57
Когда я работал в Лаборатории реактивного движения в 1990 году, LabView и «Графическое программирование» были «будущим». Видимо, они все еще есть.
Curt Hagenlocher 17.08.2008 17:25:21
Обратите внимание, что Java также будет вариант в этом году (2010). Моя команда использовала LabVIEW в прошлом году, и я ненавидел это. Мы обязательно будем использовать C (++?) В этом году.
Sophie Alpert 2.10.2009 00:57:43
+1 за Графический против Текстового вопроса программирования
thirdy 13.11.2012 04:23:56
Мой отзыв о совершенно другой области, чем робототехники. В одной из моих миссий в мире финансов я был вынужден использовать какой-то инструмент визуального программирования. Это был не labView, а EAI (инструмент, объединяющий другие части программного обеспечения). Этот EAI был визуальным инструментом со связанными блоками. Для основных «дорог» это было хорошо, но детали были очень уродливы: логика была похоронена, и нам пришлось потратить много времени, чтобы проанализировать «реальный» ход программы. Он превратился в визуальный спагетти с десятками коробок и разъемов вокруг. Техническое обслуживание было кошмаром: без рефакторинга, без автоматических тестов ...
Guillaume 18.02.2014 10:32:14
25 ОТВЕТОВ
РЕШЕНИЕ

До того, как я приехал, наша группа (доктора наук, с небольшим опытом программирования) пыталась включать и выключать приложение LabVIEW почти год. Код был неопрятным, слишком сложным (передний и задний) и, самое главное, не работал. Я увлеченный программист, но никогда не использовал LabVIEW. С небольшой помощью гуру LabVIEW, который мог помочь перевести текстовые парадигмы программирования, которые я знал, в концепции LabVIEW, можно было кодировать приложение за неделю. Дело в том, что основные концепции кодирования еще нужно выучить, язык, даже такой, как LabVIEW, это просто другой способ их выражения .

LabVIEW отлично подходит для того, для чего он изначально был разработан. т.е. брать данные с карт DAQ и отображать их на экране, возможно, с небольшими манипуляциями между ними. Тем не менее, алгоритмы программирования не проще, и я бы даже предположил, что это сложнее. Например, в большинстве процедурных языков порядок выполнения обычно следует построчно, используя псевдоматематическую нотацию (то есть y = x*x + x + 1), тогда как LabVIEW реализует это, используя серию VI, которые не обязательно следуют друг от друга (то есть слева направо) на холсте.

Более того, программирование как карьера - это больше, чем знание технических особенностей кодирования. Способность эффективно запрашивать помощь / искать ответы, писать читаемый код и работать с унаследованным кодом - все это ключевые навыки, которые, несомненно, сложнее в графическом языке, таком как LabVIEW.

Я полагаю, что некоторые аспекты графического программирования могут стать мейнстримом - использование sub-VI прекрасно воплощает принцип «черного ящика» программирования, а также используется в других языковых абстракциях, таких как Yahoo Pipes и Apple Automator - и, возможно, в некоторых будущих графических язык революционизирует способ программирования, но сам LabVIEW не является серьезным изменением парадигмы в дизайне языка, у нас все еще есть while, for, ifуправление потоком, типизация, программирование на основе событий, даже объекты. Если будущее действительно будет написано в LabVIEW, у программиста C ++ не будет особых проблем при переходе.

В качестве постскриптума я бы сказал, что C / C ++ больше подходит для робототехники, поскольку студентам, несомненно, придется в какой-то момент иметь дело со встроенными системами и ПЛИС. Знания в области программирования низкого уровня (биты, регистры и т. Д.) Были бы неоценимы для такого рода вещей.

@mendicant На самом деле LabVIEW широко используется в промышленности, особенно для систем управления. Предоставленный NASA вряд ли будет использовать его для бортовых спутниковых систем, но тогда разработка программного обеспечения для космических систем - это совсем другая игра с мячом ...

32
6.03.2010 15:18:04
FPGA могут быть выполнены в VHDL / Verilog (текстовом) или в схематическом (графическом). Кроме того, вы можете поменять их местами, так что разработчики FPGA имеют лучшее из обоих миров. Может быть полезно расширить ссылку на FPGA в своем ответе.
earlNameless 9.03.2011 18:17:17

Это не отвечает на ваш вопрос напрямую, но вы можете рассмотреть третий вариант микширования на интерпретируемом языке. Lua , например, уже используется в области робототехники. Он быстрый, легкий и может быть настроен для работы с числами с фиксированной запятой вместо плавающей запятой, так как большинство микроконтроллеров не имеют FPU. Forth - другая альтернатива с подобным использованием.

Должно быть довольно легко написать тонкий интерфейсный слой на C, а затем позволить студентам проигрывать интерпретированные сценарии. Вы даже можете настроить его так, чтобы код загружался динамически, без перекомпиляции и перепрошивки чипа. Это должно сократить цикл итераций и позволить учащимся лучше учиться, видя результаты быстрее.

Я склонен против использования визуальных инструментов, таких как LabVIEW. Кажется, я всегда сталкиваюсь с чем-то, что не работает или не работает так, как я хочу. Поэтому я предпочитаю абсолютный контроль над текстовым кодом.

6
17.08.2008 15:55:24

Я думаю, что графические языки могут быть языком будущего ..... для всех тех разработчиков MS Access, которые там работают. Там всегда будет место для чисто текстовых кодеров.

Лично я должен спросить, в чём же истинное удовольствие строить робота, если все это сделано для вас? Если вы просто поместите модуль «найди красный шар» и посмотрите, как он работает? Какое чувство гордости вы будете иметь за ваши достижения? Лично у меня не было бы много. Кроме того, чему вас научит кодирование или (очень важный) аспект программного / аппаратного интерфейса, который имеет решающее значение в робототехнике?

Я не претендую на звание эксперта в этой области, но задаю себе один вопрос: считаете ли вы, что НАСА использовало LabVIEW для кодирования марсоходов? Как вы думаете, кто-нибудь действительно выдающийся в робототехнике использует LabView?

На самом деле, если вы спросите меня, единственное, что может помочь вам в создании таких формочек для печенья, как LabVIEW, - это быть роботом на заднем дворе и ничего более. Если вы хотите что-то, что даст вам нечто большее, чем отраслевой опыт, создайте свою собственную систему типа LabVIEW. Создайте свой собственный модуль «найди мяч» или свой собственный модуль «следуй за линией». Это будет намного сложнее, но это также будет намного круче. : D

2
17.08.2008 15:59:08

Существует опубликованное исследование по теме, размещенной в National Instruments:

Изучение графического и текстового программирования для обучения DSP

В частности, он смотрит на LabVIEW против MATLAB (в отличие от C).

4
17.08.2008 16:18:10
Возможно, стоит отметить, что NI является создателем LabVIEW. :)
unwind 9.12.2008 09:57:33

Я столкнулся с несколько похожей ситуацией в исследовательской группе, в которой я сейчас работаю. Это биофизическая группа, и мы везде используем LabVIEW для управления нашими инструментами. Это прекрасно работает: легко собрать пользовательский интерфейс для управления всеми аспектами ваших инструментов, просмотра их состояния и сохранения ваших данных.

И теперь я должен остановить себя от написания 5-страничной тирады, потому что для меня LabVIEW стал кошмаром. Позвольте мне вместо этого попытаться суммировать некоторые плюсы и минусы:

Отказ от ответственности Я не эксперт LabVIEW, я мог бы сказать, что предвзятые, устаревшие или просто неправильно :)

LabVIEW профи

  • Да, это легко учиться . Многие доктора наук в нашей группе, кажется, приобрели достаточно навыков, чтобы взломать их в течение нескольких недель или даже меньше.
  • Библиотеки . Это важный момент. Вам придется тщательно исследовать это для вашей собственной ситуации (я не знаю, что вам нужно, если для этого есть хорошие библиотеки LabVIEW или есть альтернативы на других языках). В моем случае, например, найти хорошую и быструю библиотеку диаграмм в Python было серьезной проблемой, которая помешала мне переписать некоторые наши программы на Python.
  • Возможно, в вашей школе он уже установлен и работает.

LabVIEW минусы

  • Возможно, это слишком легко учиться. В любом случае, кажется, никто не утруждает себя изучением лучших практик, поэтому программы быстро превращаются в полный, непоправимый беспорядок. Конечно, это также должно произойти с текстовыми языками, если вы не будете осторожны, но IMO гораздо сложнее сделать все правильно в LabVIEW.
  • В LabVIEW, как правило, возникают серьезные проблемы с поиском sub-VI (я думаю, даже до версии 8.2). LabVIEW имеет свой собственный способ узнать, где найти библиотеки и под-VI, что позволяет очень легко полностью сломать ваше программное обеспечение. Это делает большие проекты болью, если рядом нет человека, который знает, как с этим справиться.
  • Заставить LabVIEW работать с контролем версий - это боль . Конечно, это можно сделать, но в любом случае я бы воздержался от использования встроенного VC. Проверьте LVDiff для инструмента сравнения LabVIEW, но даже не думайте о слиянии.

(Последние два пункта затрудняют работу в команде над одним проектом. Это, вероятно, важно в вашем случае)

  • Это личное, но я считаю, что многие алгоритмы просто не работают, когда программируются визуально. Это беспорядок .
    • Одним из примеров является материал, который является строго последовательным; это становится громоздким довольно быстро.
    • Трудно иметь обзор кода.
    • Если вы используете подпункты VI для небольших задач (точно так же, как хорошая практика - создавать функции, которые выполняют небольшую задачу и помещаются на одном экране), вы не можете просто дать им имена, но вы должны нарисовать значки для каждого их. Это становится очень раздражающим и обременительным всего за несколько минут, так что у вас возникает соблазн не помещать вещи в подпункт VI. Это слишком много хлопот. Кстати: создание действительно хорошей иконы может занять несколько часов. Попробуй сделать уникальный, сразу понятный, узнаваемый значок для каждого под-VI, который ты пишешь :)
  • У вас будет запястный туннель в течение недели. Гарантированный.
  • @ Брендан: слушай, слушай!

Заключительные замечания

Что касается вашего вопроса «я должен написать свои собственные модули»: я не уверен. Зависит от ваших временных ограничений. Не тратьте время на то, чтобы заново изобрести колесо, если не нужно. Слишком легко потратить дни на написание низкоуровневого кода, а затем понять, что у тебя не хватает времени. Если это означает, что вы выбираете LabVIEW, сделайте это.

Если бы были простые способы объединить LabVIEW и, например, C ++, я бы хотел услышать об этом: это может дать вам лучшее из обоих миров, но я сомневаюсь, что они есть.

Но убедитесь, что вы и ваша команда тратите время на изучение лучших практик. Глядя на код друг друга. Учимся друг у друга. Написание полезного, понятного кода. И веселиться!

И, пожалуйста, прости меня за то, что я звучу остро и, возможно, немного педантично. Просто LabVIEW стал для меня настоящим кошмаром :)

11
17.08.2008 19:44:21
LabVIEW может объединять ВП начиная с 8.5 - zone.ni.com/devzone/cda/tut/p/id/6212 8.5 также имеет инструменты для предотвращения сшивки, проблема поиска подвидов, о которой вы упомянули - zone.ni.com/devzone/ cda / tut / p / id / 6200
Chris Hamons 9.12.2009 05:57:22

Кажется, что если вы пытаетесь подготовить нашу команду к будущему программированию, то C (++) может стать лучшим путем. Похоже, что обещание общих языков программирования, построенных с использованием визуальных строительных блоков, никогда не осуществилось, и я начинаю задумываться, будут ли они когда-нибудь. Кажется, что, хотя это может быть сделано для конкретных проблемных областей, как только вы попытаетесь решить многие общие проблемы, текстовый язык программирования будет трудно победить.

Одно время я как бы увлекся идеей исполняемого UML, но кажется, что, как только вы преодолеете объектные отношения и некоторые потоки процессов, UML станет довольно жалким способом создания приложения. Представьте, что вы пытаетесь подключить все это к графическому интерфейсу. Я не возражаю против того, чтобы быть доказанным неправым, но пока кажется маловероятным, что в ближайшее время мы начнем программировать.

0
17.08.2008 21:02:37

Я думаю, что графические языки всегда будут ограничены в выразительности по сравнению с текстовыми. Сравните попытки общения в визуальных символах (например, REBUS или язык жестов) с общением, используя слова.

Для простых задач использование графического языка обычно проще, но для более сложной логики я считаю, что графические языки мешают.

Однако в этом аргументе подразумевается еще одна дискуссия: декларативное программирование и императив. Декларативное обычно лучше для всего, где вам действительно не нужен детальный контроль над тем, как что-то делается. Вы можете использовать C ++ декларативным способом, но вам потребуется больше усилий, чтобы сделать это, тогда как LABView разработан как декларативный язык.

Картинка стоит тысячи слов, но если картинка представляет тысячу слов, которые вам не нужны, и вы не можете это изменить, то в этом случае картинка бесполезна. Принимая во внимание, что вы можете создавать тысячи картинок, используя слова, указывая каждую деталь и даже явно направляя внимание зрителя.

4
17.08.2008 21:34:02

Я начал работать с LabVIEW около 2 лет назад, и теперь использую его постоянно, поэтому, возможно, он будет предвзятым, но он идеально подходит для приложений, где требуется сбор и контроль данных.

Мы используем LabVIEW в основном для тестирования, где мы проводим непрерывные измерения и контролируем газовые клапаны и корпуса ATE. Это включает в себя как цифровые, так и аналоговые входы и выходы с процедурами анализа сигналов и управления процессом, которые выполняются из графического интерфейса. Разбивая каждую часть на подвиды, мы можем перенастроить тесты одним щелчком мыши.

Не совсем то же самое, что C / C ++, но похожая реализация измерения, контроля и анализа с использованием Visual BASIC кажется сложной и трудной для сопровождения путем сравнения.

Я думаю, что процесс программирования важнее, чем реальный язык кодирования, и вы должны следовать рекомендациям по стилю для графического языка программирования. Блок-схемы LabVIEW показывают поток данных ( программирование потока данных ), поэтому должно быть легко увидеть потенциальные условия гонки, хотя у меня никогда не было проблем. Если у вас есть кодовая база C, то встраивание ее в dll позволит LabVIEW вызывать ее напрямую.

0
19.08.2008 17:57:57

Боже мой, ответ так прост. Используйте LabView .

Я запрограммировал встроенные системы на 10 лет, и я могу сказать, что, по крайней мере, без пары месяцев инфраструктуры (очень осторожная инфраструктура!) Вы не будете столь же продуктивны, как в первый день работы с LabView .

Если вы разрабатываете робота для продажи и использования в военных целях, начните с C - это хороший вызов.

В противном случае, используйте систему, которая позволяет вам попробовать самые разнообразные в кратчайшие сроки. Это LabView .

3
22.08.2008 00:47:38

Я люблю LabVIEW. Я очень рекомендую это, особенно если другие помнят, использовали что-то подобное. Обычным программистам требуется некоторое время, чтобы привыкнуть к этому, но результат гораздо лучше, если вы уже знаете, как программировать.

C / C ++ равно управляет вашей собственной памятью. Вы будете плавать в ссылках памяти и беспокоиться о них. Пойдите с LabVIEW и удостоверьтесь, что вы читаете документацию, которая идет с LabVIEW и следите за условиями гонки.

Изучать язык легко. Научиться программировать нет. Это не изменится, даже если это графический язык. Преимущество графических языков состоит в том, что легче визуализировать, что будет делать код, чем сидеть там и расшифровывать кучу текста.

Важным является не язык, а концепции программирования. Не имеет значения, на каком языке вы учитесь программировать, потому что, приложив немного усилий, вы сможете хорошо программировать на любом языке. Языки приходят и уходят.

2
22.08.2008 01:05:55

Ты в старшей школе. Сколько времени у вас есть на работу над этой программой? Сколько человек в вашей группе? Они уже знают C ++ или LabView?

Из вашего вопроса я вижу, что вы знаете C ++, а большая часть группы - нет. Я также подозреваю, что руководитель группы достаточно проницателен, чтобы заметить, что некоторые члены команды могут быть запуганы текстовым языком программирования. Это приемлемо, ты в старшей школе, а эти люди норм . Мне кажется, что обычные старшеклассники смогут понять LabView более интуитивно, чем C ++. Я предполагаю, что большинство старшеклассников, как и население в целом, боятся командной строки. Для вас разница намного меньше, но для них это день и ночь.

Вы правы, что к LabView могут применяться те же понятия, что и к C ++. У каждого есть свои сильные и слабые стороны. Ключ в выборе правильного инструмента для работы. LabView был разработан для такого рода приложений . C ++ гораздо более универсален и может применяться для решения многих других задач.

Я собираюсь рекомендовать LabView. При правильном оборудовании вы можете работать практически из коробки. Ваша команда может потратить больше времени на то, чтобы робот сделал то, что вы хотите , что и должно быть в центре внимания этой деятельности.

Графические языки не являются будущим программирования; они были одним из доступных вариантов, созданных для решения определенных типов проблем в течение многих лет. Будущее программирования - слой за слоем абстракции от машинного кода. В будущем нам будет интересно, почему мы потратили столько времени на программирование «семантики» снова и снова.

сколько мы должны полагаться на предварительно написанные модули, и сколько мы должны пытаться писать самостоятельно? Вы не должны тратить время на изобретение колеса. Если в Labview доступны драйверы устройств, используйте их. Вы можете многому научиться, скопировав код, схожий по функциям, и приспособив его к вашим потребностям - вы увидите, как другие люди решают подобные проблемы, и должны интерпретировать их решение, прежде чем сможете правильно применить его к своей проблеме. Если вы слепо копируете код, шансы заставить его работать, невелики. Вы должны быть хорошими, даже если вы копируете код.

Удачи!

1
15.09.2008 16:28:05

Я бы посоветовал вам использовать LabVIEW, так как вы можете сделать робота тем, что вы хотите делать быстрее и проще. LabVIEW был разработан с этим умом. OfCourse C (++) - отличные языки, но LabVIEW делает то, что должен делать лучше, чем все остальное. Люди могут написать действительно хорошее программное обеспечение в LabVIEW, поскольку оно предоставляет широкие возможности и поддержку для этого.

1
16.09.2008 19:16:18

У обоих вариантов есть свои достоинства; тем не менее, поскольку ваш домен является образовательным опытом, я думаю, что решение C / C ++ принесет наибольшую пользу студентам. Графическое программирование всегда будет опцией, но просто не предоставляет функциональности элегантным способом, который сделает его более эффективным, чем текстовое программирование для низкоуровневого программирования. Это неплохая вещь - весь смысл абстракции состоит в том, чтобы дать новое понимание и взгляд на проблемную область. Причина, по которой я полагаю, что многие могут быть разочарованы графическим программированием, заключается в том, что для любой конкретной программы прирост перехода от программирования на C к графическому не является почти таким же, как переход от сборки к C.

Знание графического программирования наверняка принесет пользу любому будущему программисту. Вероятно, в будущем появятся возможности, которые потребуют только знаний графического программирования, и, возможно, некоторые из ваших студентов могли бы извлечь пользу из некоторого раннего опыта работы с ним. С другой стороны, прочная основа в фундаментальных концепциях программирования, обеспечиваемая текстовым подходом, принесет пользу всем вашим студентам и, безусловно, должен быть лучшим ответом.

0
17.09.2008 07:07:59

Капитан команды считает, что LabVIEW лучше для простоты обучения и преподавания. Это правда?

Я сомневаюсь, что это было бы верно для любого отдельного языка или парадигмы. LabView, безусловно, может быть проще для людей с опытом работы в области электроники; Создание программ в нем - это просто рисование проводов. С другой стороны, такие люди могут быть уже знакомы с программированием.

Одно существенное отличие - помимо графического - в том, что LV - это программирование, основанное на потребностях (потоке). Вы начинаете с итогов и рассказываете, что нужно для этого. Традиционное программирование имеет тенденцию быть обязательным (наоборот).

Некоторые языки могут обеспечить оба. Недавно я создал многопоточную библиотеку для Lua (Lanes), и ее можно использовать для программирования по требованию в остальной императивной среде. Я знаю, что успешные роботы в основном работают в Lua ( Crazy Ivan в Lua Oh Six).

0
17.09.2008 18:36:41

Я думаю, что выбор LabVIEW или нет сводится к тому, хотите ли вы научиться программировать на широко используемом языке в качестве рыночного навыка или просто хотите, чтобы что-то было сделано. LabVIEW позволяет быстро и продуктивно выполнить работу. Как заметили другие, это не освобождает вас от магического понимания того, что вы делаете, и вполне возможно создать нечестивый беспорядок, если вы этого не сделаете - хотя, как это ни странно, наихудшими примерами плохого стиля кодирования в LabVIEW являются: как правило, совершается людьми, которые имеют опыт работы с текстовым языком и отказываются адаптироваться к тому, как работает LabVIEW, потому что они «уже знают, как программировать, черт побери!»

Это не значит, что программирование на LabVIEW, конечно, не является рыночным навыком; просто он не такой массовый, как C ++.

LabVIEW позволяет чрезвычайно легко управлять различными вещами, происходящими параллельно, что вы вполне можете иметь в ситуации управления роботом. Условия гонки в коде, который должен быть последовательным, также не должны быть проблемой (то есть, если они есть, вы делаете это неправильно): существуют простые методы, чтобы убедиться, что все происходит в правильном порядке, где это необходимо - объединение в цепочку subVI с использованием проводник ошибок или другие данные, используя уведомители или очереди, строят структуру конечного автомата, даже используя структуру последовательности LabVIEW, если это необходимо. Опять же, это просто случай, когда вам нужно время, чтобы понять инструменты, доступные в LabVIEW, и то, как они работают. Я не думаю, что необходимость делать иконки subVI очень хорошо направлена; Вы можете очень быстро создать текст, содержащий несколько слов текста, возможно, с цветом фона,

«Графические языки - путь будущего» - красная селедка, основанная на ложной дихотомии. Некоторые вещи хорошо подходят для графических языков (например, параллельный код); другие вещи подходят текстовым языкам намного лучше. Я не ожидаю, что LabVIEW и графическое программирование исчезнут или захватят весь мир.

Кстати, я был бы очень удивлен, если бы НАСА не использовало LabVIEW в космической программе. Кто-то недавно описал в списке рассылки Info-LabVIEW, как он использовал LabVIEW для разработки и тестирования замкнутого контура управления полетными поверхностями, приводимыми в действие электродвигателями на Boeing 787, и создал впечатление, что LabVIEW широко использовался при разработке самолета. Он также используется для управления в реальном времени в Большом адронном коллайдере!

В настоящее время наиболее активным местом для получения дополнительной информации и помощи с LabVIEW, помимо собственного сайта и форумов National Instruments, является LAVA .

9
2.10.2008 10:56:27
Количество невежества, отображаемое в некоторых из этих ответов, поразительно. Этот показывает некоторые реальные знания. Спасибо, некоматик!
Joe Z 16.12.2008 19:40:02

При использовании LabVIEW для моих приложений я обнаружил один огромный недостаток: организовать сложность дизайна. Как физик, я считаю, что Labview отлично подходит для прототипирования, управления приборами и математического анализа. Нет языка, на котором вы получите более быстрый и лучший результат, чем в LabVIEW. Я использую LabView с 1997 года. С 2005 года я полностью перешел на .NET Framework, так как его легче проектировать и поддерживать.

В LabVIEW должна быть нарисована простая структура «если», и она занимает много места в вашем графическом дизайне. Я только что узнал, что многие из наших коммерческих приложений трудно поддерживать. Чем сложнее становилось приложение, тем сложнее его было читать.

Теперь я использую текстовые переводы, и я намного лучше поддерживаю все. Если бы вы сравнили C ++ с LabVIEW, я бы использовал LabVIEW, но по сравнению с C # он не выиграл

1
24.10.2008 20:23:35

LabVIEW позволяет быстро начать работу и (как уже сказали другие) имеет обширную библиотеку кода для выполнения различных задач, связанных с тестированием, измерениями и контролем.

Однако самым большим недостатком LabVIEW является то, что вы теряете все инструменты, которые программисты пишут для себя.

Ваш код хранится как ВП. Это непрозрачные двоичные файлы. Это означает, что ваш код действительно не ваш, а LabVIEW. Вы не можете написать свой собственный анализатор, вы не можете написать генератор кода, вы не можете делать автоматические изменения с помощью макросов или скриптов.

Это отстой, когда у вас есть приложение 5000 VI, которое требует некоторой незначительной настройки, применяемой повсеместно. Ваша единственная возможность - пройти каждый ВП вручную, и, черт возьми, поможет вам, если вы пропустите изменение в одном ВП где-нибудь в углу.

И да, поскольку это двоичный файл, вы не можете делать diff / merge / patch, как вы можете с текстовыми языками. Это действительно делает работу с более чем одной версией кода ужасным кошмаром обслуживания.

Во что бы то ни стало, используйте LabVIEW, если вы делаете что-то простое, хотите прототипировать или не планируете поддерживать свой код.

Если вы хотите заниматься настоящим программируемым программированием, используйте текстовый язык. Возможно, вы начинаете медленнее, но в конечном итоге вы будете быстрее.

(О, и если вам нужны библиотеки DAQ, у NI также есть версии на C ++ и .Net.)

4
26.11.2008 03:38:00

Другая сила LabVIEW (помимо библиотек) - параллелизм . Это язык потока данных , что означает, что среда выполнения может обрабатывать параллелизм для вас. Поэтому, если вы делаете что-то одновременно и не хотите выполнять традиционную синхронизацию, LabVIEW может помочь вам в этом.

Будущее не принадлежит графическим языкам в их нынешнем виде. Он принадлежит тому, кто может представить представление потока данных (или другого типа программирования, ориентированного на параллелизм), которое так же просто, как графический подход, но также может быть проанализировано собственными инструментами программиста.

6
26.11.2008 14:12:41

Отказ от ответственности: я не был свидетелем LabVIEW, но я использовал несколько других графических языков, включая WebMethods Flow и Modeller, языки динамического моделирования в университете и, ну, MIT's Scratch :).

Мой опыт показывает, что графические языки могут хорошо выполнять «программную» часть программирования, но те, которые я использовал, активно мешают алгоритмике. Если ваши алгоритмы очень просты, это может быть хорошо.

С другой стороны, я не думаю, что C ++ также хорош для вашей ситуации. Вы потратите больше времени на отслеживание проблем с указателями и управлением памятью, чем на полезную работу.

Если вашим роботом можно управлять с помощью языка сценариев (Python, Ruby, Perl и т. Д.), То я думаю, что это был бы гораздо лучший выбор.

Тогда есть гибридные варианты:

Если для вашего робота нет опции сценариев, и у вас в команде есть фанат C ++, подумайте о том, чтобы использовать привязки записи этого фаната для сопоставления вашей библиотеки C ++ с языком скриптов. Это позволило бы людям с другими специальностями программировать робота более легко. Привязки будут хорошим подарком для сообщества.

Если LabVIEW позволяет это, используйте графический язык для соединения модулей, написанных на текстовом языке.

2
26.11.2008 14:51:50

Как всегда, это зависит.

Я использую LabVIEW уже около 20 лет и выполнял довольно большие виды работ, от простого DAQ до очень сложной визуализации, от элементов управления устройством до тестовых секвенсоров. Если бы это было недостаточно хорошо, я бы наверняка перешел. Тем не менее, я начал кодировать Fortran с помощью перфокарт и использовал множество языков программирования на 8-битных «машинах», начиная с Z80. Языки варьировались от Ассемблера до Бейсика, от Турбо-Паскаля до Си.

LabVIEW значительно улучшился благодаря своим обширным библиотекам для сбора и анализа данных. Однако нужно изучить другую парадигму. И вам определенно нужен трекбол ;-))

1
9.12.2008 09:22:13

Вы смотрели на Microsoft Robotics Studio? http://msdn.microsoft.com/en-us/robotics/default.aspx

Это позволяет для визуального программирования (VPL): http://msdn.microsoft.com/en-us/library/bb483047.aspx, а также современные языки, такие как C #. Я рекомендую вам хотя бы взглянуть на учебники.

0
9.12.2008 09:30:06

Я ничего не имею о LabView (или много о C / C ++), но ..

Считаете ли вы, что графические языки, такие как LabVEIW, - это будущее программирования?

Нет ...

Легче ли изучать графический язык, чем текстовый? Я думаю, что они должны быть примерно одинаково сложными для изучения.

Проще учиться? Нет, но они могут легче объяснить и понять.

Чтобы объяснить язык программирования, вы должны объяснить, что такое переменная (что удивительно сложно). Это не проблема с инструментами потокового графического / узлового кодирования, такими как интерфейс программирования LEGO Mindstroms или Quartz Composer.

Например, в этой довольно сложной программе LEGO Mindstroms - очень легко понять, что происходит ... но что если вы хотите, чтобы робот выполнилINCREASEJITTER блок 5 раз, затем двинулся вперед на 10 секунд, затем попробуйте INCREASEJITTER цикл снова? Все начинает очень быстро запутываться.

Кварцевый Композитор - отличный пример этого, и почему я не думаю, что графические языки когда-либо будут "будущим"

Это позволяет очень просто делать классные вещи (эффекты трехмерных частиц, с камерой, контролируемой средней яркостью пикселей от веб-камеры) ... но невероятно сложно делать простые вещи, такие как перебирать элементы из файла XML или хранить это среднее значение пикселя в файл.

Видя, что мы неравнодушны к тому, чтобы помогать людям учиться, насколько мы должны полагаться на заранее написанные модули и сколько мы должны пытаться писать самостоятельно? («Хорошие программисты пишут хороший код, хорошие программисты копируют отличный код. Но разве не стоит быть хорошим программистом, во-первых?)

Для обучения намного проще как объяснить, так и понять графический язык.

Тем не менее, я бы рекомендовал специализированный текстовый язык в качестве прогрессии. Например, для графики что-то вроде Processing или NodeBox . Это «нормальные» языки (Обработка - это Java, NodeBox - это Python) с укоренившимися в них очень специализированными, простыми в использовании (но невероятно мощными) фреймворками.

Важно отметить, что это очень интерактивные языки, вам не нужно писать сотни строк, чтобы нарисовать кружок на экране. Просто введите oval(100, 200, 10, 10)и нажмите кнопку запуска, и она появится! Это также делает их очень легко продемонстрировать и объяснить.

Было бы лучше познакомить вас с роботами, даже чем-то вроде LOGO - вы наберете «FORWARD 1», и черепаха переместится вперед на одну коробку. Наберите «LEFT 90», и она развернется на 90 градусов. Это очень просто относится к реальности. Вы можете визуализировать, что будет делать каждая инструкция, затем опробовать ее и подтвердить, что она действительно работает именно так.

Покажите им блестящие вещи, они по пути подберут полезные вещи, которые они изучат у C, если они будут заинтересованы или продвигаются к тому моменту, когда им нужен «настоящий» язык, у них будут все эти знания, а не столкнуться с синтаксической ошибкой и компилировать кирпичную стену ..

1
9.12.2008 10:18:44

Моя претензия к Labview (и Matlab в этом отношении) заключается в том, что, если вы планируете встраивать код во что-либо, кроме x86 (а в Labview есть инструменты для размещения виртуальных машин Labview на ARM), вам придется потратить столько сил на эту проблему. как вы можете, потому что это неэффективно.

Labview - отличный инструмент для создания прототипов: множество библиотек, легко объединяющих блоки, может быть, немного сложнее создавать сложные алгоритмы, но, вероятно, есть блок для того, что вы хотите сделать. Вы можете сделать функциональность быстро. Но если вы думаете, что можете взять этот VI и просто поместить его на устройство, вы ошибаетесь. Например, если вы делаете блок сумматора в Labview, у вас есть два входа и один выход. Какое использование памяти для этого? Три переменные ценность данных? Два? В C или C ++ вы знаете, потому что вы можете либо написать, z=x+yлибо x+=yточно знать, что делает ваш код и какова ситуация с памятью. Использование памяти может быстро возрасти, особенно потому, что (как уже отмечали другие) Labview очень параллелен. Так что будьте готовы бросить больше оперативной памяти, чем вы думали в проблеме. И больше вычислительной мощности.

Короче говоря, Labview отлично подходит для быстрого создания прототипов, но вы теряете слишком много контроля в других ситуациях. Если вы работаете с большими объемами данных или ограниченной памятью / вычислительной мощностью, используйте текстовый язык программирования, чтобы вы могли контролировать происходящее.

0
24.08.2009 18:36:49

Мой первый пост здесь :) Будь нежнее ...

Я родом из автомобильной промышленности, и теперь я в оборонной промышленности. По опыту могу сказать, что C / C ++ и LabVIEW - это действительно разные звери с разными целями. C / C ++ всегда использовался для встраиваемой работы на микроконтроллерах, потому что он был компактным, и компиляторы / инструменты были легко доступны. LabVIEW, с другой стороны, использовался для управления тестовой системой (наряду с тестовым стендом в качестве секвенсора). Большая часть тестового оборудования, которое мы использовали, была от NI, поэтому LabVIEW предоставил среду, в которой были инструменты и драйверы, необходимые для работы, а также необходимую поддержку.

С точки зрения простоты изучения, существует множество ресурсов для C / C ++ и многих веб-сайтов, на которых изложены соображения дизайна и примеры алгоритмов практически для всего, что вам нужно в свободном доступе. Для LabVIEW пользовательское сообщество, вероятно, не так разнообразно, как C / C ++, и требуется немного больше усилий для проверки и сравнения примера кода (необходимо иметь правильную версию LabVIEW и т. Д.) ... Я обнаружил, что LabVIEW довольно легко выбрать и учиться, но есть некоторые неудобства, как некоторые упоминали здесь, чтобы сделать с параллелизмом и различными другими вещами, которые требуют немного опыта, прежде чем вы осознаете их.

Таким образом, заключение после всего этого? Я бы сказал, что ОБА языки стоит изучать, потому что они действительно представляют два разных стиля программирования, и, безусловно, стоит быть осведомленным и опытным в обоих.

4
18.10.2009 06:26:57

Люди всегда сравнивают labview с C ++, и день «о labview - это высокий уровень, и в нем так много встроенной функциональности, попробуйте получить данные, выполнив выборку и отобразив данные, их так легко в labview попробовать в C ++».

Миф 1: С C ++ трудно что-либо сделать, потому что на его низком уровне и в labview уже реализовано много вещей. Проблема в том, что если вы разрабатываете роботизированную систему на C ++, вы ДОЛЖНЫ использовать библиотеки, такие как opencv, pcl ... ect, и вы будете еще умнее, если будете использовать программную среду, предназначенную для создания роботизированных систем, таких как ROS (операционная система робота). Поэтому вам нужно использовать полный набор инструментов. На самом деле, когда вы используете ROS + python / c ++ с такими библиотеками, как opencv и pcl, доступны более высокоуровневые инструменты. Я использовал робототехнику labview, и, честно говоря, широко распространенных алгоритмов, таких как ICP, там нет, и теперь вы не можете легко использовать другие библиотеки.

Миф 2. Легче ли понимать языки графического программирования?

Это зависит от ситуации. Когда вы кодируете сложный алгоритм, графические элементы займут ценное место на экране, и вам будет сложно понять метод. Чтобы понять код labview, вы должны прочитать область, сложность которой O (n ^ 2), в коде, который вы только что прочитали сверху вниз.

Что делать, если у вас есть параллельные системы. ROS реализует архитектуру на основе графов, основанную на сообщениях подписчика / издателя, реализованных с использованием обратного вызова, и довольно легко запускать и обмениваться данными несколькими программами. Разделение отдельных параллельных компонентов облегчает отладку. Например, переход по параллельному коду labview - это кошмар, потому что скачки потока управления переходят из одного места в другое. В ROS вы явно не «вытягиваете свою архитектуру, как в labview, однако вы все равно можете увидеть ее, выполнив команду ros run rqt_graph (которая покажет все подключенные узлы)

«Будущее программирования графическое». (Думаю да?)

Надеюсь, что нет, текущая реализация labview не позволяет кодировать текстовые и графические методы. (есть математика, однако это невероятно медленно)

Его трудно отлаживать, потому что вы не можете легко скрыть параллелизм.

Трудно прочитать код labview, потому что там вы должны просмотреть большую область.

Labview отлично подходит для обработки данных и обработки сигналов, но не для экспериментальной робототехники, поскольку большинство высокоуровневых компонентов, таких как SLAM (одновременная локализация и отображение), регистрация облака точек и т. Д. Отсутствуют. Даже если они добавляют эти компоненты и их легко интегрировать, как в ROS, потому что labview является проприетарным и дорогим, они никогда не поспевают за сообществом открытого исходного кода.

Таким образом, если labview - будущее для мехатроники, я изменяю свой карьерный путь на инвестиционный банкинг ... Если я не могу наслаждаться своей работой, я могу также заработать немного денег и уйти в отставку рано ...

0
14.09.2013 12:42:27