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

https://stackoverflow.com/questions/13678

08-06-2019
|

Вопрос

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

C(++):

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

Лабораторный обзор

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

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

Также:

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

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

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

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

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

Решение

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

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

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

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

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

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

Другие советы

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

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

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

Плюсы LabVIEW

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

Минусы LabVIEW

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О Боже, ответ так прост.Использование Лабораторный обзор.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Желаю удачи!

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

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

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

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

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

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

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

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

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

Нет...

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

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

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

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

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

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

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

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

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

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

В большей степени это связано с робототехникой, даже что-то вроде ЛОГОТИПА было бы хорошим введением - вы набираете "ВПЕРЕД 1", и черепаха перемещается на одну коробку вперед..Введите "ВЛЕВО 90", и он повернется на 90 градусов..Это очень просто соотносится с реальностью.Вы можете визуализировать, что будет делать каждая инструкция, затем попробовать ее и убедиться, что это действительно так работает.

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы уже заглядывали в Microsoft Robotics Studio?http://msdn.microsoft.com/en-us/robotics/default.aspx

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

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

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

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

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

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

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

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

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

"Будущее программирования за графикой". (Вы так думаете?)

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

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

Его трудно прочитать в labview, потому что там вам приходится просматривать очень большую область.

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow