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

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

C (++):

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

LabVIEW

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

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

Также:

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

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


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

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


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

Ответов (25)

Решение

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

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

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

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

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

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

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

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

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

LabVIEW профи

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

Минусы LabVIEW

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Код labview сложно читать, потому что там нужно смотреть на очень большую площадь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы когда-нибудь видели Microsoft Robotics Studio? http://msdn.microsoft.com/en-us/robotics/default.aspx

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

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

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

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

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

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

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

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