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

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

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

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

Я считаю, что некоторые аспекты графического программирования может стать мейнстримом - использование суб-VIs идеально воплощает в себе основные 'black-box' программирования, а также используется в других языках такие абстракции, как Yahoo труб и Яблоко автоматизатор - и, возможно, некоторые будущие графический язык будет революционизировать способ мы программы, но LabVIEW себя не массовый сдвиг парадигмы в языке дизайна, у нас еще есть while, for, if поток управления, типажей, событийно-управляемое Программирование, даже предметы. Если будущее действительно будет написано в LabVIEW, то программисту C++ не составит большого труда пересечь его.

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

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

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

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

Отказ от ответственности я не эксперт LabVIEW, я мог бы сказать вещи, которые предвзяты, out-of-date или просто неправильно :)

LabVIEW плюсов

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

LabVIEW минусы

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Он специально смотрит на LabVIEW против MATLAB (в отличие от C).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На самом деле, если вы спросите меня, единственное, что можно сделать с помощью печенья-резака, например, LabVIEW, чтобы построить это, чтобы подготовить вас к тому, чтобы быть каким-то задворком робота-строителя и ничего больше. Если вы хотите что-то, что даст вам нечто большее, чем опыт работы в отрасли, создайте свою собственную систему типа 'LabVIEW'. Создайте свой собственный модуль find-the-ball или свой собственный модуль follow-the-line. Это будет намного сложнее, но и намного круче тоже. :Д

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

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

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

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

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

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

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

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

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

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

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

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

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

Желаю удачи!

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

Как всегда, все зависит от обстоятельств.

Я использую LabVIEW уже около 20 лет и выполнял довольно большие виды работ, от простой DAQ до очень сложной визуализации, от управления устройствами до тестовых секвенсоров. Если бы это было недостаточно хорошо, я бы наверняка поменялся. Тем не менее, я начал кодировать Fortran с перфокарт и использовал целую кучу языков программирования на 8-битном 'machines', начиная с Z80-основанных. Языки варьировались от ассемблера до BASIC, от Турбо-Pascal до C.

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

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

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

№..

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

Легче учиться? Нет, но их легче объяснить и понять.

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

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

Quartz Composer-отличный пример этого, и почему я не думаю, что графические языки когда-нибудь "be the future"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Миф 1: трудно что-либо сделать с C++ its, потому что его уровень настолько низок, а labview уже многое реализовал. Проблема в том , что если вы разрабатываете роботизированную систему в C++, вы MUST используете библиотеки, такие как opencv, pcl .. ЭСТ и Вы были бы еще более умны, если бы использовали программную структуру, предназначенную для создания роботизированных систем, таких как ROS (robot operating system). Поэтому вам необходимо использовать полный набор инструментов. Инфакт есть более высокоуровневые инструменты, доступные при использовании, ROS + python/c++ с библиотеками, такими как opencv и pcl. Я использовал labview робототехнику и откровенно часто используемые алгоритмы, такие как ICP, не существуют, и это не похоже на то, что вы можете легко использовать другие библиотеки сейчас.

МИФ 2: легче ли понимать графические языки программирования

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

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

"The future of programming is graphical." (вы так думаете?)

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

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

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

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

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