Текстовые и графические языки программирования
Я являюсь частью команды роботов средней школы, и есть некоторые споры о том, какой язык использовать для программирования нашего робота. Мы выбираем между C (или, возможно, C++) и LabVIEW. Есть плюсы для каждого языка.
C (++):
- Широко используемый
- Хорошая подготовка к будущему (большинство позиций программирования требуют текстовых программистов.)
- Мы можем расширить нашу кодовую базу C с прошлого года
- Позволяет нам лучше понять, что делает наш робот.
LabVIEW
- Проще визуализировать ход программы (блоки и провода, а не строки кода)
- Проще учить (предположительно...)
- "Будущее программирования графическое". (Думаю так?)
- Ближе к истории Robolab, что некоторые новые участники могут иметь.
- Не нужно глубоко знать, что происходит. Просто скажите модулю найти красный шар, не нужно знать, как.
Это очень сложное решение для нас, и мы уже давно обсуждаем это. Исходя из этих плюсов для каждого языка и полученного опыта, как вы думаете, какой вариант лучше? Имейте в виду, что мы не обязательно идем к чистой эффективности. Мы также надеемся подготовить наших программистов к будущему программированию.
Также:
- Считаете ли вы, что графические языки, такие как LabVEIW, - это будущее программирования?
- Легче ли изучать графический язык, чем текстовый? Я думаю, что они должны быть примерно одинаково сложными для изучения.
- Видя, что мы неравнодушны к тому, чтобы помогать людям учиться, насколько мы должны полагаться на заранее написанные модули и сколько мы должны пытаться писать самостоятельно? ("Хорошие программисты пишут хороший код, хорошие программисты копируют отличный код. Но разве не стоит быть хорошим программистом, во-первых?)
Спасибо за совет!
Изменить: я хотел бы подчеркнуть этот вопрос больше: капитан команды считает, что LabVIEW лучше для его простоты обучения и преподавания. Это правда? Я думаю, что C можно научить так же легко, и задачи начального уровня все еще будут рядом с C. Мне бы очень хотелось услышать ваше мнение. Есть ли причина, по которой печатать while{} должно быть сложнее, чем создавать поле while? Разве не настолько интуитивно понятно, что программа перемещается построчно, изменяясь только с помощью ifs и циклов, так как интуитивно понятно, что программа движется через провод, изменяемый только с помощью ifs и циклов!?
Еще раз спасибо!
Редактировать: я только что понял, что это подпадает под тему "языковые дебаты". Я надеюсь, что все в порядке, потому что речь идет о том, что лучше для конкретной отрасли программирования с определенными целями. Если нет... прости...
25 ответов
До того, как я приехал, наша группа (ученые PhD, с небольшим опытом программирования) пыталась включать и выключать приложение LabVIEW в течение почти года. Код был неопрятным, слишком сложным (фронт и бэкэнд) и, самое главное, не работал. Я увлеченный программист, но никогда не использовал LabVIEW. С небольшой помощью гуру LabVIEW, который мог помочь перевести текстовые парадигмы программирования, которые я знал, в концепции LabVIEW, можно было кодировать приложение за неделю. Дело в том, что основные концепции кодирования еще нужно выучить, язык, даже такой, как LabVIEW, это просто другой способ их выражения.
LabVIEW отлично подходит для того, для чего он изначально был разработан. т.е. брать данные с карт DAQ и отображать их на экране, возможно, с небольшими манипуляциями между ними. Тем не менее, алгоритмы программирования не проще, и я бы даже предположил, что это сложнее. Например, в большинстве процедурных языков порядок выполнения обычно сопровождается построчно, используя псевдоматематическую нотацию (т.е. y = x*x + x + 1) тогда как LabVIEW будет реализовывать это, используя серию VI, которые не обязательно следуют друг от друга (то есть слева направо) на холсте.
Более того, программирование как карьера - это больше, чем знание технических особенностей кодирования. Возможность эффективно запрашивать помощь / искать ответы, писать читаемый код и работать с унаследованным кодом - все это ключевые навыки, которые, несомненно, сложнее в графическом языке, таком как LabVIEW.
Я полагаю, что некоторые аспекты графического программирования могут стать мейнстримом - использование вспомогательных VI прекрасно воплощает принцип "черного ящика" программирования, а также используется в других языковых абстракциях, таких как Yahoo Pipes и Apple Automator - и, возможно, в некоторых будущих графических язык революционизирует способ программирования, но сам LabVIEW не является серьезным изменением парадигмы в дизайне языка, мы все еще имеем while, for, if управление потоком, приведение типов, программирование на основе событий, даже объекты. Если будущее действительно будет написано в LabVIEW, у программиста C++ не будет особых проблем с переходом.
В качестве постскриптума я бы сказал, что C/C++ больше подходит для робототехники, поскольку студентам, несомненно, придется в какой-то момент иметь дело со встроенными системами и ПЛИС. Знания в области программирования низкого уровня (биты, регистры и т. Д.) Были бы неоценимы для такого рода вещей.
@mendicant На самом деле LabVIEW широко используется в промышленности, особенно для систем управления. Предоставленный NASA вряд ли будет использовать его для бортовых спутниковых систем, но тогда разработка программного обеспечения для космических систем - это совсем другая игра с мячом...
Я столкнулся с несколько похожей ситуацией в исследовательской группе, в которой я сейчас работаю. Это биофизическая группа, и мы везде используем LabVIEW для управления нашими инструментами. Это прекрасно работает: легко собрать пользовательский интерфейс для управления всеми аспектами ваших инструментов, просмотра их состояния и сохранения ваших данных.
И теперь я должен остановить себя от написания 5-страничной тирады, потому что для меня LabVIEW стал кошмаром. Позвольте мне вместо этого попытаться суммировать некоторые плюсы и минусы:
Отказ от ответственности Я не эксперт LabVIEW, я мог бы сказать, что предвзятые, устаревшие или просто неправильно:)
LabVIEW профи
- Да, это легко учиться. Многие доктора наук в нашей группе, кажется, приобрели достаточно навыков, чтобы взломать их в течение нескольких недель или даже меньше.
- Библиотеки. Это важный момент. Вам придется тщательно исследовать это для вашей собственной ситуации (я не знаю, что вам нужно, если для этого есть хорошие библиотеки LabVIEW или есть альтернативы на других языках). В моем случае, нахождение, например, хорошей, быстрой библиотеки диаграмм в Python было большой проблемой, которая помешала мне переписать некоторые из наших программ на Python.
- Возможно, в вашей школе он уже установлен и работает.
LabVIEW минусы
- Это, возможно, слишком легко учиться. В любом случае, похоже, никто не утруждает себя изучением лучших практик, поэтому программы быстро превращаются в полный, непоправимый беспорядок. Конечно, это также должно произойти с текстовыми языками, если вы не будете осторожны, но IMO намного сложнее сделать все правильно в LabVIEW.
- В LabVIEW, как правило, возникают серьезные проблемы с поиском sub-VI (даже до версии 8.2, я думаю). LabVIEW имеет свой собственный способ узнать, где найти библиотеки и под-VI, что позволяет очень легко полностью сломать ваше программное обеспечение. Это делает большие проекты болью, если рядом нет человека, который знает, как с этим справиться.
- Заставить LabVIEW работать с контролем версий - это боль. Конечно, это можно сделать, но в любом случае я бы воздержался от использования встроенного VC. Проверьте LVDiff для инструмента сравнения LabVIEW, но даже не думайте о слиянии.
(Последние два пункта затрудняют работу в команде над одним проектом. Это, вероятно, важно в вашем случае)
- Это личное, но я считаю, что многие алгоритмы просто не работают, когда программируются визуально. Это беспорядок.
- Одним из примеров является материал, который является строго последовательным; это становится громоздким довольно быстро.
- Трудно иметь обзор кода.
- Если вы используете подпункты VI для небольших задач (точно так же, как хорошая практика - создавать функции, выполняющие небольшую задачу и помещающиеся на одном экране), вы не можете просто дать им имена, но вы должны нарисовать значки для каждого из них. Это становится очень раздражающим и громоздким всего за несколько минут, так что вы очень искушаетесь не помещать вещи в подпункт VI. Это слишком много хлопот. Кстати: создание действительно хорошей иконы может занять профессиональные часы. Попробуй сделать уникальный, сразу понятный, узнаваемый значок для каждого под-VI, который ты пишешь:)
- У вас будет запястный туннель в течение недели. Гарантированный.
- @ Брендан: слушай, слушай!
Заключительные замечания
Что касается вашего вопроса "я должен написать свои собственные модули": я не уверен. Зависит от ваших временных ограничений. Не тратьте время на то, чтобы заново изобрести колесо, если не нужно. Слишком легко потратить дни на написание низкоуровневого кода, а затем понять, что у тебя не хватает времени. Если это означает, что вы выбираете LabVIEW, сделайте это.
Если бы были простые способы объединить LabVIEW и, например, C++, я бы хотел услышать об этом: это может дать вам лучшее из обоих миров, но я сомневаюсь, что они есть.
Но убедитесь, что вы и ваша команда тратите время на изучение лучших практик. Глядя на код друг друга. Учимся друг у друга. Написание полезного, понятного кода. И веселиться!
И, пожалуйста, прости меня за то, что я звучу остро и, возможно, немного педантично. Просто LabVIEW стал для меня настоящим кошмаром:)
Я думаю, что выбор LabVIEW или нет сводится к тому, хотите ли вы научиться программировать на общеупотребительном языке в качестве рыночного навыка или просто хотите закончить работу. LabVIEW позволяет быстро и продуктивно выполнить работу. Как заметили другие, это не освобождает вас от магического понимания того, что вы делаете, и вполне возможно создать нечестивый беспорядок, если вы этого не сделаете - хотя, как это ни странно, наихудшими примерами плохого стиля кодирования в LabVIEW являются: как правило, это люди, которые имеют опыт работы с текстовым языком и отказываются адаптироваться к работе LabVIEW, потому что они "уже знают, как программировать, черт побери!"
Это не значит, что программирование на LabVIEW, конечно, не является рыночным навыком; просто он не такой массовый, как C++.
LabVIEW позволяет чрезвычайно легко управлять различными вещами, происходящими параллельно, что вы вполне можете иметь в ситуации управления роботом. Условия гонки в коде, который должен быть последовательным, также не должны быть проблемой (то есть, если они есть, вы делаете это неправильно): существуют простые методы для обеспечения того, чтобы все происходило в правильном порядке, где это необходимо - объединение в цепочку subVI с использованием проводник ошибок или другие данные, используя уведомители или очереди, строят структуру конечного автомата, даже используя структуру последовательности LabVIEW, если это необходимо. Опять же, это просто случай, когда вам нужно время, чтобы понять инструменты, доступные в LabVIEW, и то, как они работают. Я не думаю, что необходимость делать иконки subVI очень хорошо направлена; Вы можете очень быстро создать текст, содержащий несколько слов текста, возможно, с цветом фона, и это подойдет для большинства целей.
"Графические языки - путь будущего" - красная селедка, основанная на ложной дихотомии. Некоторые вещи хорошо подходят для графических языков (например, параллельный код); другие вещи подходят текстовым языкам намного лучше. Я не ожидаю, что LabVIEW и графическое программирование либо уйдут, либо захватят весь мир.
Кстати, я был бы очень удивлен, если бы НАСА не использовало LabVIEW в космической программе. Кто-то недавно описал в списке рассылки Info-LabVIEW, как он использовал LabVIEW для разработки и тестирования замкнутого контура управления полетными поверхностями, приводимыми в действие электродвигателями на Boeing 787, и создал впечатление, что LabVIEW широко использовался при разработке самолета. Он также используется для управления в реальном времени в Большом адронном коллайдере!
На данный момент наиболее активным местом для получения дополнительной информации и помощи с LabVIEW, помимо собственного сайта и форумов National Instruments, по-видимому, является LAVA.
Другая сила LabVIEW (помимо библиотек) - параллелизм. Это язык потока данных, что означает, что среда выполнения может обрабатывать параллелизм для вас. Так что, если вы делаете что-то в высокой степени параллельное и не хотите выполнять традиционную синхронизацию, LabVIEW может помочь вам в этом.
Будущее не принадлежит графическим языкам в их нынешнем виде. Он принадлежит тому, кто может представить представление потока данных (или другого типа программирования, ориентированного на параллелизм), которое так же просто, как и графический подход, но также может быть проанализировано собственными инструментами программиста.
Это не отвечает на ваш вопрос напрямую, но вы можете рассмотреть третий вариант микширования на интерпретируемом языке. Lua, например, уже используется в области робототехники. Он быстрый, легкий и может быть настроен для работы с числами с фиксированной запятой вместо плавающей запятой, так как большинство микроконтроллеров не имеют FPU. Forth - другая альтернатива с подобным использованием.
Должно быть довольно легко написать тонкий интерфейсный слой на C, а затем позволить студентам проигрывать интерпретированные сценарии. Вы даже можете настроить его так, чтобы код загружался динамически, без перекомпиляции и перепрошивки чипа. Это должно сократить цикл итераций и позволить учащимся лучше учиться, видя результаты быстрее.
Я склонен против использования визуальных инструментов, таких как LabVIEW. Кажется, я всегда сталкиваюсь с чем-то, что не работает или не работает так, как я хочу. Поэтому я предпочитаю абсолютный контроль, который вы получаете с помощью текстового кода.
LabVIEW позволяет быстро начать работу и (как уже говорили другие) имеет обширную библиотеку кода для выполнения различных задач, связанных с тестированием, измерениями и контролем.
Однако самое большое падение LabVIEW заключается в том, что вы теряете все инструменты, которые программисты пишут для себя.
Ваш код хранится как ВП. Это непрозрачные двоичные файлы. Это означает, что ваш код на самом деле не ваш, а LabVIEW. Вы не можете написать свой собственный анализатор, вы не можете написать генератор кода, вы не можете делать автоматические изменения с помощью макросов или скриптов.
Это отстой, когда у вас есть приложение 5000 VI, которое требует некоторой небольшой настройки, применяемой повсеместно. Ваша единственная возможность - пройти каждый ВП вручную, и, черт возьми, поможет вам, если вы пропустите изменение в одном ВП где-нибудь в углу.
И да, поскольку это двоичный файл, вы не можете делать diff/merge/patch, как вы можете с текстовыми языками. Это действительно делает работу с более чем одной версией кода ужасным кошмаром ремонтопригодности.
Во что бы то ни стало, используйте LabVIEW, если вы делаете что-то простое, хотите прототипировать или не планируете поддерживать свой код.
Если вы хотите заниматься реальным программируемым программированием, используйте текстовый язык. Возможно, вы начнете медленнее, но в конечном итоге вы будете быстрее.
(О, и если вам нужны библиотеки DAQ, у NI также есть версии на C++ и.Net.)
Мой первый пост здесь:) Будь нежнее...
Я родом из автомобильной промышленности, и теперь я в оборонной промышленности. По опыту могу сказать, что C/C++ и LabVIEW - это действительно разные звери с разными целями. C/C++ всегда использовался для встроенной работы на микроконтроллерах, потому что он был компактным, и компиляторы / инструменты были легко доступны. LabVIEW, с другой стороны, использовался для управления тестовой системой (наряду с тестовым стендом в качестве секвенсора). Большая часть используемого нами тестового оборудования была от NI, поэтому LabVIEW предоставил среду, в которой у нас были инструменты и драйверы, необходимые для работы, а также поддержка, которую мы хотели.
С точки зрения простоты изучения, существует множество ресурсов для C/C++ и множество веб-сайтов, на которых изложены соображения дизайна и примеры алгоритмов практически для всего, что вам нужно в свободном доступе. Для LabVIEW сообщество пользователей, вероятно, не так разнообразно, как C/C++, и требуется немного больше усилий для проверки и сравнения примера кода (необходимо иметь правильную версию LabVIEW и т. Д.) ... Я обнаружил, что LabVIEW довольно легко выбрать и учиться, но есть неприятности, как некоторые упоминали здесь, чтобы сделать с параллелизмом и различными другими вещами, которые требуют немного опыта, прежде чем вы осознаете их.
Таким образом, заключение после всего этого? Я бы сказал, что ОБА языки стоит изучать, потому что они действительно представляют два разных стиля программирования, и, безусловно, стоит быть осведомленным и опытным в обоих.
Существует опубликованное исследование по теме, размещенной в National Instruments:
Изучение графического и текстового программирования для обучения DSP
В частности, он смотрит на LabVIEW против MATLAB (в отличие от C).
Я думаю, что графические языки всегда будут ограничены в выразительности по сравнению с текстовыми. Сравните попытки общения в визуальных символах (например, REBUS или язык жестов) с общением, используя слова.
Для простых задач использование графического языка обычно проще, но для более сложной логики я считаю, что графические языки мешают.
Однако в этом аргументе подразумевается еще одна дискуссия: декларативное программирование и императив. Декларативное обычно лучше для всего, где вам действительно не нужен детальный контроль над тем, как что-то делается. Вы можете использовать C++ декларативным способом, но вам потребуется больше усилий, чтобы сделать это, тогда как LABView разработан как декларативный язык.
Картинка стоит тысячи слов, но если картинка представляет тысячу слов, которые вам не нужны, и вы не можете это изменить, то в этом случае картинка бесполезна. Принимая во внимание, что вы можете создавать тысячи картинок, используя слова, указывая каждую деталь и даже явно фокусируя внимание зрителя.
Боже мой, ответ так прост. Используйте LabView.
Я программировал встроенные системы в течение 10 лет, и я могу сказать, что без хотя бы пары месяцев инфраструктуры (очень осторожная инфраструктура!) Вы не будете столь же продуктивны, как в первый день работы с LabView.
Если вы разрабатываете робота для продажи и использования в военных целях, начните с C - это хороший вызов.
В противном случае, используйте систему, которая позволяет вам попробовать самые разнообразные в кратчайшие сроки. Это LabView.
Я думаю, что графические языки могли бы стать языком будущего..... для всех тех разработчиков MS Access, которые там работают. Там всегда будет место для чисто текстовых кодеров.
Лично я должен спросить, в чём же истинное удовольствие строить робота, если все это сделано для вас? Если вы просто поместите модуль "найди красный шар" и посмотрите, как он работает? Какое чувство гордости вы будете иметь за ваши достижения? Лично у меня не было бы много. Кроме того, чему вас научит кодирование или (очень важный) аспект программного / аппаратного интерфейса, который имеет решающее значение в робототехнике?
Я не претендую на звание эксперта в этой области, но задаю себе один вопрос: считаете ли вы, что НАСА использовало LabVIEW для кодирования марсоходов? Как вы думаете, кто-нибудь действительно выдающийся в робототехнике использует LabView?
На самом деле, если вы спросите меня, единственное, что может помочь вам использовать такие инструменты для вырезки печенья, как LabVIEW, это быть каким-то создателем роботов на заднем дворе и ничего более. Если вы хотите что-то, что даст вам нечто большее, чем отраслевой опыт, создайте свою собственную систему типа LabVIEW. Создайте свой собственный модуль "найди мяч" или свой собственный модуль "следуй за линией". Это будет намного сложнее, но это также будет намного круче.:D
Отказ от ответственности: я не был свидетелем LabVIEW, но я использовал несколько других графических языков, включая WebMethods Flow и Modeller, языки динамического моделирования в университете и, ну, MIT's Scratch:).
Мой опыт показывает, что графические языки могут хорошо выполнять "слесарную" часть программирования, но те, которые я использовал, активно мешают алгоритмике. Если ваши алгоритмы очень просты, это может быть хорошо.
С другой стороны, я не думаю, что C++ также хорош для вашей ситуации. Вы потратите больше времени на отслеживание проблем с указателями и управлением памятью, чем на полезную работу.
Если вашим роботом можно управлять с помощью скриптового языка (Python, Ruby, Perl и т. Д.), То я думаю, что это был бы гораздо лучший выбор.
Тогда есть гибридные варианты:
Если для вашего робота нет опции сценариев, и у вас в команде есть фанат C++, подумайте о том, чтобы использовать привязки записи этого фаната для сопоставления вашей библиотеки C++ с языком скриптов. Это позволило бы людям с другими специальностями программировать робота более легко. Привязки будут хорошим подарком для сообщества.
Если LabVIEW позволяет это, используйте графический язык для соединения модулей, написанных на текстовом языке.
Я люблю LabVIEW. Я очень рекомендую это, особенно если другие помнят, использовали что-то подобное. Обычным программистам нужно некоторое время, чтобы привыкнуть к этому, но результат будет намного лучше, если вы уже знаете, как программировать.
C / C++ равно управляет вашей собственной памятью. Вы будете плавать в ссылках памяти и беспокоиться о них. Пойдите с LabVIEW и удостоверьтесь, что вы читаете документацию, которая идет с LabVIEW и следите за условиями гонки.
Изучать язык легко. Научиться программировать нет. Это не изменится, даже если это графический язык. Преимущество графических языков состоит в том, что легче визуализировать, что будет делать код, чем сидеть и расшифровывать кучу текста.
Важно не язык, а концепции программирования. Не имеет значения, на каком языке вы учитесь программировать, потому что, приложив немного усилий, вы сможете хорошо программировать на любом языке. Языки приходят и уходят.
Ты в старшей школе. Сколько времени у вас есть на работу над этой программой? Сколько человек в вашей группе? Они уже знают C++ или LabView?
Из вашего вопроса я вижу, что вы знаете C++, а большая часть группы - нет. Я также подозреваю, что руководитель группы достаточно проницателен, чтобы заметить, что некоторые члены команды могут быть запуганы текстовым языком программирования. Это приемлемо, ты в старшей школе, а эти люди норм. Я чувствую, что обычные старшеклассники смогут понять LabView более интуитивно, чем C++. Я предполагаю, что большинство школьников, как и население в целом, боятся командной строки. Для вас разница намного меньше, но для них это день и ночь.
Вы правы, что к LabView могут применяться те же понятия, что и к C++. У каждого есть свои сильные и слабые стороны. Ключ в выборе правильного инструмента для работы. LabView был разработан для такого рода приложений. C++ гораздо более универсален и может применяться для решения многих других задач.
Я собираюсь рекомендовать LabView. При правильном оборудовании вы можете работать практически из коробки. Ваша команда может потратить больше времени на то, чтобы робот сделал то, что вы хотите, что и должно быть в центре внимания этой деятельности.
Графические языки не являются будущим программирования; в течение многих лет они были одним из доступных вариантов, созданных для решения определенных типов проблем. Будущее программирования - слой за слоем абстракции от машинного кода. В будущем нам будет интересно, почему мы потратили столько времени на программирование "семантики" снова и снова.
сколько мы должны полагаться на предварительно написанные модули, и сколько мы должны пытаться писать самостоятельно? Вы не должны тратить время на изобретение колеса. Если в Labview доступны драйверы устройств, используйте их. Вы можете многому научиться, копируя код, схожий по функциям, и адаптируя его к вашим потребностям - вы узнаете, как другие люди решают подобные проблемы, и должны интерпретировать их решение, прежде чем сможете правильно применить его к своей проблеме. Если вы слепо копируете код, шансы заставить его работать, невелики. Вы должны быть хорошими, даже если вы копируете код.
Удачи!
Я ничего не имею о LabView (или много о C/C++), но..
Считаете ли вы, что графические языки, такие как LabVEIW, - это будущее программирования?
Нет...
Легче ли изучать графический язык, чем текстовый? Я думаю, что они должны быть примерно одинаково сложными для изучения.
Проще учиться? Нет, но их легче объяснить и понять.
Чтобы объяснить язык программирования, вы должны объяснить, что такое переменная (что на удивление сложно). Это не проблема с инструментами потокового графического / узлового кодирования, такими как интерфейс программирования LEGO Mindstroms или Quartz Composer.
Например, это довольно сложная программа LEGO Mindstroms - очень легко понять, что происходит... но что, если вы хотите, чтобы робот запускал INCREASEJITTER блокировать 5 раз, затем двигаться вперед на 10 секунд, затем снова попробовать цикл INCREASEJITTER? Все начинает очень быстро запутываться..
Кварцевый Композитор является отличным примером этого, и почему я не думаю, что графические языки когда-либо будут "будущим"
Это позволяет очень просто делать классные вещи (эффекты трехмерных частиц с помощью камеры, контролируемой средней яркостью пикселей от веб-камеры)... но невероятно сложно делать простые вещи, такие как перебирать элементы из файла XML или хранить это среднее значение пикселя в файл.
Видя, что мы неравнодушны к тому, чтобы помогать людям учиться, насколько мы должны полагаться на заранее написанные модули и сколько мы должны пытаться писать самостоятельно? ("Хорошие программисты пишут хороший код, хорошие программисты копируют отличный код. Но разве не стоит быть хорошим программистом, во-первых?)
Для обучения намного проще как объяснить, так и понять графический язык.
Тем не менее, я бы рекомендовал специализированный текстовый язык в качестве прогрессии. Например, для графики что-то вроде Processing или NodeBox. Это "нормальные" языки (Обработка - это Java, NodeBox - это Python) с укоренившимися в них очень специализированными, простыми в использовании (но невероятно мощными) фреймворками.
Важно отметить, что это очень интерактивные языки, вам не нужно писать сотни строк, чтобы нарисовать кружок на экране. oval(100, 200, 10, 10) и нажмите кнопку запуска, и она появляется! Это также делает их очень легко продемонстрировать и объяснить.
Было бы лучше познакомить вас с роботами, даже чем-то вроде LOGO - вы наберете "FORWARD 1", и черепаха переместится вперед на одну коробку. Наберите "LEFT 90", и она развернется на 90 градусов. Это очень просто относится к реальности. Вы можете визуализировать, что будет делать каждая инструкция, затем опробовать ее и подтвердить, что она действительно работает именно так.
Покажите им блестящие вещи, они по пути подберут полезные вещи, которые они изучат у C, если они будут заинтересованы или продвигаются до того момента, когда им нужен "настоящий" язык, у них будут все эти знания, а не столкнуться с синтаксической ошибкой и компилировать кирпичную стену..
Я бы посоветовал вам использовать LabVIEW, поскольку вы можете сделать робота тем, что вы хотите делать быстрее и проще. LabVIEW был разработан с этим умом. OfCourse C(++) - отличные языки, но LabVIEW делает то, что должен делать лучше, чем все остальное. Люди могут написать действительно хорошее программное обеспечение в LabVIEW, поскольку оно предоставляет широкие возможности и поддержку для этого.
При использовании LabVIEW для моих приложений я обнаружил один огромный недостаток: организовать сложность дизайна. Как физик, я считаю, что Labview отлично подходит для прототипирования, управления приборами и математического анализа. Нет языка, на котором вы получите более быстрый и лучший результат, чем в LabVIEW. Я использую LabView с 1997 года. С 2005 года я полностью перешел на.NET Framework, так как его легче проектировать и поддерживать.
В LabVIEW должна быть нарисована простая структура "если", и она занимает много места в вашем графическом дизайне. Я только что узнал, что многие из наших коммерческих приложений трудно поддерживать. Чем сложнее становилось приложение, тем сложнее его было читать.
Теперь я использую текстовые переводы, и я намного лучше поддерживаю все. Если бы вы сравнили C++ с LabVIEW, я бы использовал LabVIEW, но по сравнению с C# он не выиграл
Как всегда, это зависит.
Я использую LabVIEW уже около 20 лет и выполнял довольно большие виды работ, от простого DAQ до очень сложной визуализации, от элементов управления устройством до тестовых секвенсоров. Если бы это было недостаточно хорошо, я бы наверняка перешел. Тем не менее, я начал кодировать Fortran с помощью перфокарт и использовал множество языков программирования на 8-битных "машинах", начиная с Z80. Языки варьировались от Ассемблера до Бейсика, от Турбо-Паскаля до Си.
LabVIEW значительно улучшился благодаря своим обширным библиотекам для сбора и анализа данных. Однако необходимо изучить другую парадигму. И вам определенно нужен трекбол;-))
Моя претензия к Labview (и Matlab в этом отношении) заключается в том, что если вы планируете встраивать код во что-то, кроме x86 (а в Labview есть инструменты для размещения VI Labview на ARM), вам придется потратить столько же сил на эту проблему как вы можете, потому что это неэффективно.
Labview - отличный инструмент для создания прототипов: множество библиотек, легко объединяющих блоки, может быть, немного сложнее создавать сложные алгоритмы, но, вероятно, есть блок для того, что вы хотите сделать. Вы можете получить функциональность быстро. Но если вы думаете, что можете взять этот VI и просто поместить его на устройство, вы ошибаетесь. Например, если вы делаете блок сумматора в Labview, у вас есть два входа и один выход. Какое использование памяти для этого? Три переменные ценность данных? Два? В C или C++ вы знаете, потому что вы можете написать z=x+y или же x+=y и вы точно знаете, что делает ваш код и какова ситуация с памятью. Использование памяти может быстро возрасти, особенно потому, что (как уже отмечали другие) Labview очень параллелен. Так что будьте готовы бросить больше оперативной памяти, чем вы думали в проблеме. И больше вычислительной мощности.
Короче говоря, Labview отлично подходит для быстрого создания прототипов, но вы теряете слишком много контроля в других ситуациях. Если вы работаете с большими объемами данных или ограниченными возможностями памяти / обработки, используйте текстовый язык программирования, чтобы вы могли контролировать происходящее.
Кажется, что если вы пытаетесь подготовить нашу команду к будущему программированию, то C(++) может быть лучшим путем. Похоже, что обещание общих языков программирования, построенных с использованием визуальных строительных блоков, никогда не осуществилось, и я начинаю задумываться, будут ли они когда-нибудь. Кажется, что, хотя это может быть сделано для конкретных проблемных областей, как только вы попытаетесь решить многие общие проблемы, текстовый язык программирования будет трудно победить.
Одно время я как бы увлекся идеей исполняемого UML, но кажется, что, как только вы преодолеете объектные отношения и некоторые потоки процессов, UML станет довольно жалким способом создания приложения. Представьте, что вы пытаетесь подключить все это к графическому интерфейсу. Я не возражаю против того, чтобы оказаться неправым, но пока кажется маловероятным, что в ближайшее время мы начнем программировать.
Вы смотрели на Microsoft Robotics Studio? http://msdn.microsoft.com/en-us/robotics/default.aspx
Это позволяет для визуального программирования (VPL): http://msdn.microsoft.com/en-us/library/bb483047.aspx а также современные языки, такие как C#. Я призываю вас хотя бы взглянуть на учебники.
В обоих вариантах есть свои достоинства; тем не менее, поскольку ваш домен является образовательным опытом, я думаю, что решение C/C++ принесет наибольшую пользу студентам. Графическое программирование всегда будет опцией, но просто не обеспечивает функциональности элегантным способом, который сделает его более эффективным, чем текстовое программирование для низкоуровневого программирования. Это неплохая вещь - весь смысл абстракции состоит в том, чтобы дать новое понимание и взгляд на проблемную область. Причина, по которой я полагаю, что многие могут быть разочарованы графическим программированием, заключается в том, что для любой конкретной программы прирост перехода от программирования на C к графическому отличается от перехода от ассемблера к C.
Знание графического программирования наверняка принесет пользу любому будущему программисту. Вероятно, в будущем появятся возможности, которые потребуют только знаний графического программирования, и, возможно, некоторые из ваших студентов могли бы извлечь пользу из некоторого раннего опыта работы с ним. С другой стороны, прочная основа в фундаментальных концепциях программирования, обеспечиваемая текстовым подходом, принесет пользу всем вашим студентам и, безусловно, должен быть лучшим ответом.
Люди всегда сравнивают labview с C++, и день "о, labview - это высокий уровень, и он имеет так много встроенной функциональности, попробуйте получить данные, выполнив загрузку и отобразив данные, их так легко в labview попробовать в C++".
Миф 1: С C++ трудно что-либо сделать, потому что на его низком уровне и в labview уже реализовано много вещей. Проблема в том, что если вы разрабатываете роботизированную систему на C++, вы ДОЛЖНЫ использовать библиотеки, такие как opencv, pcl... ect, и вы будете еще умнее, если будете использовать программную среду, предназначенную для создания роботизированных систем, таких как ROS (операционная система робота). Поэтому вам нужно использовать полный набор инструментов. На самом деле, когда вы используете ROS + python/ C++ с такими библиотеками, как opencv и pcl, доступны более высокоуровневые инструменты. Я использовал робототехнику labview, и, честно говоря, широко распространенных алгоритмов, таких как ICP, там нет, и теперь вы не можете легко использовать другие библиотеки.
Миф 2. Легче ли понимать языки графического программирования?
Это зависит от ситуации. Когда вы кодируете сложный алгоритм, графические элементы займут ценное место на экране, и вам будет сложно понять метод. Чтобы понять код labview, вы должны прочитать область, сложность которой составляет O(n^2), в коде, который вы только что прочитали сверху вниз.
Что делать, если у вас есть параллельные системы. ROS реализует архитектуру на основе графов, основанную на сообщениях подписчика / издателя, реализованных с использованием обратного вызова, и довольно легко запускать и обмениваться данными несколькими программами. Разделение отдельных параллельных компонентов облегчает отладку. Например, переход по параллельному коду labview - кошмар, потому что скачки потока управления формируются из одного места в другое. В ROS вы явно не "вытягиваете свою архитектуру, как в labview, однако вы все равно можете увидеть ее, выполнив команду ros run rqt_graph (которая покажет все подключенные узлы)
"Будущее программирования графическое". (Думаю так?)
Я надеюсь, что нет, текущая реализация labview не позволяет кодировать текстовые и графические методы. (есть математика, однако это невероятно медленно)
Его трудно отлаживать, потому что вы не можете легко скрыть параллелизм.
Трудно прочитать код labview, потому что там вы должны просмотреть большую область.
Labview отлично подходит для обработки данных и обработки сигналов, но не для экспериментальной робототехники, поскольку большинство высокоуровневых компонентов, таких как SLAM (одновременная локализация и отображение), регистрация облака точек и т. Д. Отсутствуют. Даже если они добавляют эти компоненты и их легко интегрировать, как в ROS, потому что labview является проприетарным и дорогим, они никогда не поспевают за сообществом открытого кода.
Таким образом, если labview - будущее для мехатроники, я изменяю свой карьерный путь на инвестиционный банкинг... Если я не могу наслаждаться своей работой, я могу также заработать немного денег и уйти в отставку рано...
Я начал работать с LabVIEW около 2 лет назад и теперь использую его все время, поэтому он может быть предвзятым, но он идеально подходит для приложений, где требуется сбор и контроль данных.
Мы используем LabVIEW в основном для тестирования, где мы проводим непрерывные измерения и контролируем газовые клапаны и корпуса ATE. Это включает в себя как цифровые, так и аналоговые входы и выходы с процедурами анализа сигналов и управления процессом, которые выполняются из графического интерфейса. Разбивая каждую часть на подвиды, мы можем перенастроить тесты одним щелчком мыши.
Не совсем то же самое, что C/C++, но похожая реализация измерения, контроля и анализа с использованием Visual BASIC кажется сложной и трудной для сопровождения путем сравнения.
Я думаю, что процесс программирования более важен, чем сам язык программирования, и вы должны следовать рекомендациям по стилю графического языка программирования. Блок-схемы LabVIEW показывают поток данных ( программирование потока данных), поэтому должно быть легко увидеть потенциальные условия гонки, хотя у меня никогда не было проблем. Если у вас есть кодовая база C, то встраивание ее в dll позволит LabVIEW вызывать ее напрямую.
Капитан команды считает, что LabVIEW лучше для простоты обучения и преподавания. Это правда?
Я сомневаюсь, что это было бы верно для любого отдельного языка или парадигмы. LabView, безусловно, может быть проще для людей с опытом работы в области электроники; Создание программ в нем - это "просто" рисование проводов. С другой стороны, такие люди могут быть уже знакомы с программированием.
Одно существенное отличие, помимо графического, заключается в том, что LV - это программирование, основанное на спросе. Вы начинаете с результата и рассказываете, что для этого нужно. Традиционное программирование имеет тенденцию быть обязательным (наоборот).
Некоторые языки могут обеспечить оба. Недавно я создал многопоточную библиотеку для Lua (Lanes), и ее можно использовать для программирования по требованию в остальной императивной среде. Я знаю, что успешные роботы в основном работают в Lua ( Crazy Ivan в Lua Oh Six).